Re: [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

Hi Nimroy,

Thanks for looking at this.

On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:
> 
> On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:
> > Users of intel_gt_retire_requests_timeout() expect 0 return value on
> > success.  However, we have no protection from passing back 0 potentially
> > returned by a call to dma_fence_wait_timeout() when it succedes right
> > after its timeout has expired.
> >
> > Replace 0 with -ETIME before potentially using the timeout value as return
> > code, so -ETIME is returned if there are still some requests not retired
> > after timeout, 0 otherwise.
> >
> > v2: Move the added lines down so flush_submission() is not affected.
> >
> > Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with 
retire_request")
> > Signed-off-by: Janusz Krzysztofik 
> > Cc: sta...@vger.kernel.org # v5.5+
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
> >   1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/
drm/i915/gt/intel_gt_requests.c
> > index edb881d756309..3ac4603eeb4ee 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > @@ -199,6 +199,9 @@ out_active: spin_lock(&timelines->lock);
> > if (remaining_timeout)
> > *remaining_timeout = timeout;
> >   
> > +   if (!timeout)
> > +   timeout = -ETIME;
> 
> This will return error, -ETIME when 0 timeout is passed, 
> intel_gt_retire_requests().

Yes, but only when active_count is not 0 after we loop through 
timelines->active_list calling retire_requests() on each and counting up 
failures in active_count.

> We don't want that. 

When 0 timeout is passed to intel_gt_retire_requests(), do we really want it 
to return 0 unconditionally, or are we rather interested if those calls to 
retire_requests() succeeded?

> I think you can use a separate variable to store 
> return val from the dma_fence_wait_timeout()
> 
> 
> Regards,
> 
> Nirmoy
> 
> > +
> > return active_count ? timeout : 0;

If active count is 0, we return 0 regardless of timeout value, and that's OK.  
However, if active_count is not 0, we shouldn't return 0, I believe, we should 
return either remaining time if some left, or error (-ETIME) if not.  If you 
think I'm wrong, please explain why.

Thanks,
Janusz

> >   }
> >   
> 

Re: [PATCH v4 00/10] Initial support for Cadence MHDP(HDMI/DP) for i.MX8MQ

[Alexander Stein]

Hello Sandor,

thanks for the updated series.

Am Montag, 21. November 2022, 08:23:50 CET schrieb Sandor Yu:
> The patch set initial support for Cadence MHDP(HDMI/DP) DRM bridge
> drivers and Cadence HDP-TX PHY(HDMI/DP) drivers for iMX8MQ.
> 
> The patch set compose of DRM bridge drivers and PHY drivers.
> Both of them need the followed two patches to pass build.
>   drm: bridge: cadence: convert mailbox functions to macro functions
>   phy: Add HDMI configuration options
> 
> DRM bridges driver patches:
>   dts-bingings: display: bridge: Add MHDP HDMI bindings for i.MX8MQ
>   drm: bridge: cadence: Add MHDP DP driver for i.MX8MQ
>   dts-bindings: display: bridge: Add MHDP DP bindings for i.MX8MQ
>   drm: bridge: cadence: Add MHDP HDMI driver for i.MX8MQ
> 
> PHY driver patches:
>   dts-bindings: phy: Add Cadence HDP-TX DP PHY bindings
>   phy: cadence: Add driver for HDP-TX DisplyPort PHY
>   dts-bindings: phy: Add Cadence HDP-TX HDMI PHY bindings
>   phy: cadence: Add driver for HDP-TX HDMI PHY
> 
> v3->v4:
> dt-bindings:
> - Correct dt-bindings coding style and address review comments.
> - Add apb_clk description.
> - Add output port for HDMI/DP connector
> PHY:
> - Alphabetically sorted in Kconfig and Makefile for DP and HDMI PHY
> - Remove unused registers define from HDMI and DP PHY drivers.
> - More description in phy_hdmi.h.
> - Add apb_clk to HDMI and DP phy driver.
> HDMI/DP:
> - Use get_unaligned_le32() to replace hardcode type conversion
>   in HDMI AVI infoframe data fill function.
> - Add mailbox mutex lock in HDMI/DP driver for phy functions
>   to reslove race conditions between HDMI/DP and PHY drivers.
> - Add apb_clk to both HDMI and DP driver.
> - Rename some function names and add prefix with "cdns_hdmi/cdns_dp".
> - Remove bpc 12 and 16 optional that not supported.

With the apb_clk enabled now, I can use both HDMI and PHY driver as modules 
now. Thanks!

Best regards,
Alexander

> v2->v3:
> Address comments for dt-bindings files.
> - Correct dts-bindings file names
>   Rename phy-cadence-hdptx-dp.yaml to cdns,mhdp-imx8mq-dp.yaml
>   Rename phy-cadence-hdptx-hdmi.yaml to cdns,mhdp-imx8mq-hdmi.yaml
> - Drop redundant words and descriptions.
> - Correct hdmi/dp node name.
> 
> v2 is a completely different version compared to v1.
> Previous v1 can be available here [1].
> 
> v1->v2:
> - Reuse Cadence mailbox access functions from mhdp8546 instead of
>   rockchip DP.
> - Mailbox access functions be convert to marco functions
>   that will be referenced by HDP-TX PHY(HDMI/DP) driver too.
> - Plain bridge instead of component driver.
> - Standalone Cadence HDP-TX PHY(HDMI/DP) driver.
> - Audio driver are removed from the patch set, it will be add in another
>   patch set later.
> 
> [1]
> https://patchwork.kernel.org/project/linux-rockchip/cover/cover.1590982881.
> git.sandor...@nxp.com/
> 
> Sandor Yu (10):
>   drm: bridge: cadence: convert mailbox functions to macro functions
>   dt-bindings: display: bridge: Add MHDP DP for i.MX8MQ
>   drm: bridge: cadence: Add MHDP DP driver for i.MX8MQ
>   phy: Add HDMI configuration options
>   dt-bindings: display: bridge: Add MHDP HDMI for i.MX8MQ
>   drm: bridge: cadence: Add MHDP HDMI driver for i.MX8MQ
>   dt-bindings: phy: Add Cadence HDP-TX DP PHY
>   phy: cadence: Add driver for HDP-TX DisplyPort PHY
>   dt-bindings: phy: Add Cadence HDP-TX HDMI PHY
>   phy: cadence: Add driver for HDP-TX HDMI PHY
> 
>  .../display/bridge/cdns,mhdp-imx8mq-dp.yaml   |   93 ++
>  .../display/bridge/cdns,mhdp-imx8mq-hdmi.yaml |   93 ++
>  .../bindings/phy/cdns,hdptx-dp-phy.yaml   |   68 ++
>  .../bindings/phy/cdns,hdptx-hdmi-phy.yaml |   52 +
>  drivers/gpu/drm/bridge/cadence/Kconfig|   25 +
>  drivers/gpu/drm/bridge/cadence/Makefile   |3 +
>  drivers/gpu/drm/bridge/cadence/cdns-dp-core.c | 1071 +
>  .../gpu/drm/bridge/cadence/cdns-hdmi-core.c   | 1018 
>  .../gpu/drm/bridge/cadence/cdns-mhdp-common.h |  400 ++
>  .../drm/bridge/cadence/cdns-mhdp8546-core.c   |  197 +--
>  .../drm/bridge/cadence/cdns-mhdp8546-core.h   |1 -
>  drivers/phy/cadence/Kconfig   |   16 +
>  drivers/phy/cadence/Makefile  |2 +
>  drivers/phy/cadence/phy-cadence-hdptx-dp.c|  737 
>  drivers/phy/cadence/phy-cadence-hdptx-hdmi.c  |  891 ++
>  include/drm/bridge/cdns-mhdp-mailbox.h|  240 
>  include/linux/phy/phy-hdmi.h  |   38 +
>  include/linux/phy/phy.h   |7 +-
>  18 files changed, 4755 insertions(+), 197 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-dp.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/cdns,mhdp-imx8mq-hdmi.yaml
> create mode 100644
> Documentation/devicetree/bindings/phy/cdns,hdptx-dp-phy.yaml create mode
> 100644 Documentation/devicetree/bindings/phy/cdns,hdptx-hdmi-phy.yaml
> create mode 100644 drivers/gpu/drm/br

Re: [PATCH v2 1/2] drm/i915: Fix negative value passed as remaining time

[Janusz Krzysztofik]

On Friday, 18 November 2022 11:42:21 CET Janusz Krzysztofik wrote:
> Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
> with GuC") extended the API of intel_gt_retire_requests_timeout() with an
> extra argument 'remaining_timeout', intended for passing back unconsumed
> portion of requested timeout when 0 (success) is returned.  However, when
> request retirement happens to succeed despite an error returned by a call
> to dma_fence_wait_timeout(), that error code (a negative value) is passed
> back instead of remaining time.  If we then pass that negative value
> forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG
> will be triggered.
> 
> If request retirement succeeds but an error code other than -ETIME is
> passed back via remaininig_timeout, we have no clue on how much of
> the initial timeout might have been left for spending it on waiting for
> GuC to become idle.  Then, we have no choice other than fail in that case
> -- do it.  

Looking at this again, I think we should ignore those errors, like they have 
been already ignored by intel_gt_retire_requests_timeout() returning 0, and 
call intel_uc_wait_for_idle() with 0 timeout.

I'll submit new version if you agree.

Thanks,
Janusz

> However, if -ETIME is returned via remaining_timeout then we
> know that no more time has been left.  Then, pass 0 timeout value to
> intel_uc_wait_for_idle() to give it a chance to return success if GuC is
> already idle.
> 
> v2: Fix the issue on the caller side, not the provider.
> 
> Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work 
with GuC")
> Signed-off-by: Janusz Krzysztofik 
> Cc: sta...@vger.kernel.org # v5.15+
> ---
>  drivers/gpu/drm/i915/gt/intel_gt.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/
intel_gt.c
> index 0325f071046ca..5d612ba547d23 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -677,8 +677,15 @@ int intel_gt_wait_for_idle(struct intel_gt *gt, long 
timeout)
>   return -EINTR;
>   }
>  
> - return timeout ? timeout : intel_uc_wait_for_idle(>->uc,
> -   
remaining_timeout);
> + if (timeout)
> + return timeout;
> +
> + if (remaining_timeout == -ETIME)
> + remaining_timeout = 0;
> + else if (remaining_timeout < 0)
> + return remaining_timeout;
> +
> + return intel_uc_wait_for_idle(>->uc, remaining_timeout);
>  }
>  
>  int intel_gt_init(struct intel_gt *gt)
> 

Re: [Intel-gfx] [PATCH] drm/i915: Fix workarounds on Gen2-3

[Tvrtko Ursulin]

On 18/11/2022 17:14, Matt Roper wrote:

On Fri, Nov 18, 2022 at 11:52:49AM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

In 3653727560d0 ("drm/i915: Simplify internal helper function signature")
I broke the old platforms by not noticing engine workaround init does not
initialize the list on old platforms. Fix it by always initializing which
already does the right thing by mostly not doing anything if there aren't
any workarounds on the list.

Signed-off-by: Tvrtko Ursulin 
Fixes: 3653727560d0 ("drm/i915: Simplify internal helper function signature")
Reported-by: Ville Syrjälä 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 213160f29ec3..4d7a01b45e09 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2991,7 +2991,7 @@ general_render_compute_wa_init(struct intel_engine_cs 
*engine, struct i915_wa_li
  static void
  engine_init_workarounds(struct intel_engine_cs *engine, struct i915_wa_list 
*wal)
  {
-   if (I915_SELFTEST_ONLY(GRAPHICS_VER(engine->i915) < 4))
+   if (GRAPHICS_VER(engine->i915) < 4)
return;


Do we even need this early return at all?  As far as I can see, letting
this function run its course doesn't wind up having any effect or cause
any problems (you still wind up with an empty list).


True, it looks to me like that as well, now that you are pointing it 
out. Btw originally I was most perplexed by the "selftests only" 
annotation, but did not find time to go digging through history to 
figure out why was that even needed.


I left the return as is for now and pushed it to fix the breakage. Will 
try to revisit this at some point. Thanks for the review!


Regards,

Tvrtko



Regardless,

Reviewed-by: Matt Roper 

  
  	engine_fake_wa_init(engine, wal);

@@ -3016,9 +3016,6 @@ void intel_engine_init_workarounds(struct intel_engine_cs 
*engine)
  {
struct i915_wa_list *wal = &engine->wa_list;
  
-	if (GRAPHICS_VER(engine->i915) < 4)

-   return;
-
wa_init_start(wal, engine->gt, "engine", engine->name);
engine_init_workarounds(engine, wal);
wa_init_finish(wal);
--
2.34.1

[PATCH v4 0/3] add color management support for the crtc

[Kalyan Thota]

Add color management support for the crtc provided there are
enough dspps that can be allocated from the catalog

Kalyan Thota (3):
  drm/msm/disp/dpu1: pin 1 crtc to 1 encoder
  drm/msm/disp/dpu1: add helper to know if display is builtin
  drm/msm/disp/dpu1: add color management support for the crtc

 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  5 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h|  5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 33 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  6 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 24 ++---
 5 files changed, 60 insertions(+), 13 deletions(-)

-- 
2.7.4

[PATCH v4 2/3] drm/msm/disp/dpu1: add helper to know if display is builtin

[Kalyan Thota]

Since DRM encoder type for few encoders can be similar
(like eDP and DP), get the connector type for a given
encoder to differentiate between builtin and pluggable
displays.

Changes in v1:
- add connector type in the disp_info (Dmitry)
- add helper functions to know encoder type
- update commit text reflecting the change

Changes in v2:
- avoid hardcode of connector type for DSI as it may not be true (Dmitry)
- get the HPD information from encoder bridge

Changes in v3:
- use connector type instead of bridge ops in determining
connector (Dmitry)

Changes in v4:
- get type from the drm connector rather from bridge connector (Dmitry)

Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 26 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  6 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 9c6817b..96db7fb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -217,6 +217,32 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
 };
 
+bool dpu_encoder_is_builtin(struct drm_encoder *encoder)
+{
+   struct drm_connector *connector;
+   struct drm_connector_list_iter conn_iter;
+   struct drm_device *dev = encoder->dev;
+   int type = 0;
+
+   drm_connector_list_iter_begin(dev, &conn_iter);
+   drm_for_each_connector_iter(connector, &conn_iter) {
+   if (drm_connector_has_possible_encoder(connector, encoder)) {
+   type = connector->connector_type;
+   break;
+   }
+   }
+   drm_connector_list_iter_end(&conn_iter);
+
+   switch (type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_DPI:
+   return true;
+   default:
+   return false;
+   }
+}
 
 bool dpu_encoder_is_widebus_enabled(const struct drm_encoder *drm_enc)
 {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 9e7236e..7f3d823 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -224,4 +224,10 @@ void dpu_encoder_cleanup_wb_job(struct drm_encoder 
*drm_enc,
  */
 bool dpu_encoder_is_valid_for_commit(struct drm_encoder *drm_enc);
 
+/**
+ * dpu_encoder_is_builtin - find if the encoder is of type builtin
+ * @drm_enc:Pointer to previously created drm encoder structure
+ */
+bool dpu_encoder_is_builtin(struct drm_encoder *drm_enc);
+
 #endif /* __DPU_ENCODER_H__ */
-- 
2.7.4

[PATCH v4 3/3] drm/msm/disp/dpu1: add color management support for the crtc

[Kalyan Thota]

Add color management support for the crtc provided there are
enough dspps that can be allocated from the catalog.

Changes in v1:
- cache color enabled state in the dpu crtc obj (Dmitry)
- simplify dspp allocation while creating crtc (Dmitry)
- register for color when crtc is created (Dmitry)

Changes in v2:
- avoid primary encoders in the documentation (Dmitry)

Changes in v3:
- add ctm for builtin encoders (Dmitry)

Changes in v4:
- few nits (Dmitry)

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 5 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 6 +-
 4 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 4170fbe..6cacaaf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1571,7 +1571,7 @@ static const struct drm_crtc_helper_funcs 
dpu_crtc_helper_funcs = {
 
 /* initialize crtc */
 struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
-   struct drm_plane *cursor)
+   struct drm_plane *cursor, bool ctm)
 {
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
@@ -1583,6 +1583,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev, 
struct drm_plane *plane,
 
crtc = &dpu_crtc->base;
crtc->dev = dev;
+   dpu_crtc->color_enabled = ctm;
 
spin_lock_init(&dpu_crtc->spin_lock);
atomic_set(&dpu_crtc->frame_pending, 0);
@@ -1604,7 +1605,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev, 
struct drm_plane *plane,
 
drm_crtc_helper_add(crtc, &dpu_crtc_helper_funcs);
 
-   drm_crtc_enable_color_mgmt(crtc, 0, true, 0);
+   drm_crtc_enable_color_mgmt(crtc, 0, dpu_crtc->color_enabled, 0);
 
/* save user friendly CRTC name for later */
snprintf(dpu_crtc->name, DPU_CRTC_NAME_SIZE, "crtc%u", crtc->base.id);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 539b68b..792b4f0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -136,6 +136,7 @@ struct dpu_crtc_frame_event {
  * @enabled   : whether the DPU CRTC is currently enabled. updated in the
  *  commit-thread, not state-swap time which is earlier, so
  *  safe to make decisions on during VBLANK on/off work
+ * @color_enabled : whether crtc supports color management
  * @feature_list  : list of color processing features supported on a crtc
  * @active_list   : list of color processing features are active
  * @dirty_list: list of color processing features are dirty
@@ -164,6 +165,7 @@ struct dpu_crtc {
u64 play_count;
ktime_t vblank_cb_time;
bool enabled;
+   bool color_enabled;
 
struct list_head feature_list;
struct list_head active_list;
@@ -269,10 +271,11 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc);
  * @dev: dpu device
  * @plane: base plane
  * @cursor: cursor plane
+ * @ctm: ctm flag
  * @Return: new crtc object or error
  */
 struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
-  struct drm_plane *cursor);
+  struct drm_plane *cursor, bool ctm);
 
 /**
  * dpu_crtc_register_custom_event - api for enabling/disabling crtc event
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 96db7fb..a585036 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -571,6 +571,7 @@ bool dpu_encoder_use_dsc_merge(struct drm_encoder *drm_enc)
 static struct msm_display_topology dpu_encoder_get_topology(
struct dpu_encoder_virt *dpu_enc,
struct dpu_kms *dpu_kms,
+   struct dpu_crtc *dpu_crtc,
struct drm_display_mode *mode)
 {
struct msm_display_topology topology = {0};
@@ -599,7 +600,7 @@ static struct msm_display_topology dpu_encoder_get_topology(
else
topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
 
-   if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
+   if (dpu_crtc->color_enabled) {
if (dpu_kms->catalog->dspp &&
(dpu_kms->catalog->dspp_count >= topology.num_lm))
topology.num_dspp = topology.num_lm;
@@ -634,6 +635,7 @@ static int dpu_encoder_virt_atomic_check(
struct drm_display_mode *adj_mode;
struct msm_display_topology topology;
struct dpu_global_state *global_state;
+   struct dpu_crtc *dpu_crtc;
int i = 0;

[PATCH v4 1/3] drm/msm/disp/dpu1: pin 1 crtc to 1 encoder

[Kalyan Thota]

Pin each crtc with one encoder. This arrangement will
disallow crtc switching between encoders and also will
facilitate to advertise certain features on crtc based
on encoder type.

Changes in v1:
- use drm_for_each_encoder macro while iterating through
  encoder list (Dmitry)

Changes in v2:
- make sure no encoder miss to have a crtc (Dmitry)
- revisit various factors in deciding the crtc count
  such as num_mixers, num_sspp (Dmitry)

Changes in v3:
- none

Changes in v4:
- use max_crtc_count instead of num_encoders in WARN (Dmitry)

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Kalyan Thota 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 7a5fabc..d967eef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -747,6 +747,7 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
 
int primary_planes_idx = 0, cursor_planes_idx = 0, i, ret;
int max_crtc_count;
+
dev = dpu_kms->dev;
priv = dev->dev_private;
catalog = dpu_kms->catalog;
@@ -763,7 +764,7 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
drm_for_each_encoder(encoder, dev)
num_encoders++;
 
-   max_crtc_count = min(catalog->mixer_count, num_encoders);
+   max_crtc_count = num_encoders;
 
/* Create the planes, keeping track of one primary/cursor per crtc */
for (i = 0; i < catalog->sspp_count; i++) {
@@ -795,22 +796,25 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
primary_planes[primary_planes_idx++] = plane;
}
 
-   max_crtc_count = min(max_crtc_count, primary_planes_idx);
+   /*
+* All the platforms should have at least 1 primary plane for a
+* crtc. The below warn should help in setting up the catalog
+*/
+   WARN_ON(max_crtc_count > primary_planes_idx);
 
/* Create one CRTC per encoder */
-   for (i = 0; i < max_crtc_count; i++) {
+   i = 0;
+   drm_for_each_encoder(encoder, dev) {
crtc = dpu_crtc_init(dev, primary_planes[i], cursor_planes[i]);
if (IS_ERR(crtc)) {
ret = PTR_ERR(crtc);
return ret;
}
priv->crtcs[priv->num_crtcs++] = crtc;
+   encoder->possible_crtcs = 1 << drm_crtc_index(crtc);
+   i++;
}
 
-   /* All CRTCs are compatible with all encoders */
-   drm_for_each_encoder(encoder, dev)
-   encoder->possible_crtcs = (1 << priv->num_crtcs) - 1;
-
return 0;
 }
 
-- 
2.7.4

[PATCH 3/5] kobject: kset_uevent_ops: make filter() callback take a const *

[Greg Kroah-Hartman]

The filter() callback in struct kset_uevent_ops does not modify the
kobject passed into it, so make the pointer const to enforce this
restriction.  When doing so, fix up all existing filter() callbacks to
have the correct signature to preserve the build.

Cc: "Rafael J. Wysocki" 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/base/bus.c| 2 +-
 drivers/base/core.c   | 4 ++--
 drivers/dma-buf/dma-buf-sysfs-stats.c | 2 +-
 include/linux/kobject.h   | 2 +-
 kernel/params.c   | 2 +-
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 7ca47e5b3c1f..4ec6dbab73be 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -163,7 +163,7 @@ static struct kobj_type bus_ktype = {
.release= bus_release,
 };
 
-static int bus_uevent_filter(struct kobject *kobj)
+static int bus_uevent_filter(const struct kobject *kobj)
 {
const struct kobj_type *ktype = get_ktype(kobj);
 
diff --git a/drivers/base/core.c b/drivers/base/core.c
index a79b99ecf4d8..005a2b092f3e 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2362,12 +2362,12 @@ static struct kobj_type device_ktype = {
 };
 
 
-static int dev_uevent_filter(struct kobject *kobj)
+static int dev_uevent_filter(const struct kobject *kobj)
 {
const struct kobj_type *ktype = get_ktype(kobj);
 
if (ktype == &device_ktype) {
-   struct device *dev = kobj_to_dev(kobj);
+   const struct device *dev = kobj_to_dev(kobj);
if (dev->bus)
return 1;
if (dev->class)
diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c 
b/drivers/dma-buf/dma-buf-sysfs-stats.c
index 2bba0babcb62..f69d68122b9b 100644
--- a/drivers/dma-buf/dma-buf-sysfs-stats.c
+++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
@@ -132,7 +132,7 @@ void dma_buf_stats_teardown(struct dma_buf *dmabuf)
 
 
 /* Statistics files do not need to send uevents. */
-static int dmabuf_sysfs_uevent_filter(struct kobject *kobj)
+static int dmabuf_sysfs_uevent_filter(const struct kobject *kobj)
 {
return 0;
 }
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 5a2d58e10bf5..640f59d4b3de 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -135,7 +135,7 @@ struct kobj_uevent_env {
 };
 
 struct kset_uevent_ops {
-   int (* const filter)(struct kobject *kobj);
+   int (* const filter)(const struct kobject *kobj);
const char *(* const name)(struct kobject *kobj);
int (* const uevent)(struct kobject *kobj, struct kobj_uevent_env *env);
 };
diff --git a/kernel/params.c b/kernel/params.c
index 5b92310425c5..d2237209ceda 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -926,7 +926,7 @@ static const struct sysfs_ops module_sysfs_ops = {
.store = module_attr_store,
 };
 
-static int uevent_filter(struct kobject *kobj)
+static int uevent_filter(const struct kobject *kobj)
 {
const struct kobj_type *ktype = get_ktype(kobj);
 
-- 
2.38.1

Re: [Linaro-mm-sig] [PATCH 3/5] kobject: kset_uevent_ops: make filter() callback take a const *

[Christian König]

Am 21.11.22 um 10:46 schrieb Greg Kroah-Hartman:

The filter() callback in struct kset_uevent_ops does not modify the
kobject passed into it, so make the pointer const to enforce this
restriction.  When doing so, fix up all existing filter() callbacks to
have the correct signature to preserve the build.

Cc: "Rafael J. Wysocki" 
Cc: Sumit Semwal 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Greg Kroah-Hartman 


Acked-by: Christian König  for the changes to 
the DMA-buf subsystem.



---
  drivers/base/bus.c| 2 +-
  drivers/base/core.c   | 4 ++--
  drivers/dma-buf/dma-buf-sysfs-stats.c | 2 +-
  include/linux/kobject.h   | 2 +-
  kernel/params.c   | 2 +-
  5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 7ca47e5b3c1f..4ec6dbab73be 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -163,7 +163,7 @@ static struct kobj_type bus_ktype = {
.release= bus_release,
  };
  
-static int bus_uevent_filter(struct kobject *kobj)

+static int bus_uevent_filter(const struct kobject *kobj)
  {
const struct kobj_type *ktype = get_ktype(kobj);
  
diff --git a/drivers/base/core.c b/drivers/base/core.c

index a79b99ecf4d8..005a2b092f3e 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2362,12 +2362,12 @@ static struct kobj_type device_ktype = {
  };
  
  
-static int dev_uevent_filter(struct kobject *kobj)

+static int dev_uevent_filter(const struct kobject *kobj)
  {
const struct kobj_type *ktype = get_ktype(kobj);
  
  	if (ktype == &device_ktype) {

-   struct device *dev = kobj_to_dev(kobj);
+   const struct device *dev = kobj_to_dev(kobj);
if (dev->bus)
return 1;
if (dev->class)
diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c 
b/drivers/dma-buf/dma-buf-sysfs-stats.c
index 2bba0babcb62..f69d68122b9b 100644
--- a/drivers/dma-buf/dma-buf-sysfs-stats.c
+++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
@@ -132,7 +132,7 @@ void dma_buf_stats_teardown(struct dma_buf *dmabuf)
  
  
  /* Statistics files do not need to send uevents. */

-static int dmabuf_sysfs_uevent_filter(struct kobject *kobj)
+static int dmabuf_sysfs_uevent_filter(const struct kobject *kobj)
  {
return 0;
  }
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 5a2d58e10bf5..640f59d4b3de 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -135,7 +135,7 @@ struct kobj_uevent_env {
  };
  
  struct kset_uevent_ops {

-   int (* const filter)(struct kobject *kobj);
+   int (* const filter)(const struct kobject *kobj);
const char *(* const name)(struct kobject *kobj);
int (* const uevent)(struct kobject *kobj, struct kobj_uevent_env *env);
  };
diff --git a/kernel/params.c b/kernel/params.c
index 5b92310425c5..d2237209ceda 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -926,7 +926,7 @@ static const struct sysfs_ops module_sysfs_ops = {
.store = module_attr_store,
  };
  
-static int uevent_filter(struct kobject *kobj)

+static int uevent_filter(const struct kobject *kobj)
  {
const struct kobj_type *ktype = get_ktype(kobj);
  

Re: [PATCH AUTOSEL 6.0 38/44] drm/amdgpu: Unlock bo_list_mutex after error handling

[Michel Dänzer]

On 11/19/22 03:11, Sasha Levin wrote:
> From: Philip Yang 
> 
> [ Upstream commit 64f65135c41a75f933d3bca236417ad8e9eb75de ]
> 
> Get below kernel WARNING backtrace when pressing ctrl-C to kill kfdtest
> application.
> 
> If amdgpu_cs_parser_bos returns error after taking bo_list_mutex, as
> caller amdgpu_cs_ioctl will not unlock bo_list_mutex, this generates the
> kernel WARNING.
> 
> Add unlock bo_list_mutex after amdgpu_cs_parser_bos error handling to
> cleanup bo_list userptr bo.
> 
>  WARNING: kfdtest/2930 still has locks held!
>  1 lock held by kfdtest/2930:
>   (&list->bo_list_mutex){+.+.}-{3:3}, at: amdgpu_cs_ioctl+0xce5/0x1f10 
> [amdgpu]
>   stack backtrace:
>dump_stack_lvl+0x44/0x57
>get_signal+0x79f/0xd00
>arch_do_signal_or_restart+0x36/0x7b0
>exit_to_user_mode_prepare+0xfd/0x1b0
>syscall_exit_to_user_mode+0x19/0x40
>do_syscall_64+0x40/0x80
> 
> Signed-off-by: Philip Yang 
> Reviewed-by: Christian König 
> Signed-off-by: Alex Deucher 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index b7bae833c804..9d59f83c8faa 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -655,6 +655,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser 
> *p,
>   }
>   mutex_unlock(&p->bo_list->bo_list_mutex);
>   }
> + mutex_unlock(&p->bo_list->bo_list_mutex);
>   return r;
>  }
>  

Looks doubtful that this is a correct backport — there's an identical 
mutex_unlock call just above.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

RE: [PATCH 585/606] backlight: adp8860: Convert to i2c's .probe_new()

[Hennerich, Michael]

> -Original Message-
> From: Uwe Kleine-König 
> Sent: Freitag, 18. November 2022 23:45
> To: Angel Iglesias ; Lee Jones
> ; Grant Likely ; Wolfram
> Sang ; Hennerich, Michael
> ; Lee Jones ; Daniel
> Thompson ; Jingoo Han
> ; Helge Deller 
> Cc: linux-...@vger.kernel.org; ker...@pengutronix.de; Uwe Kleine-König
> ; dri-devel@lists.freedesktop.org; linux-
> fb...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: [PATCH 585/606] backlight: adp8860: Convert to i2c's .probe_new()
> 
> 
> From: Uwe Kleine-König 
> 
> .probe_new() doesn't get the i2c_device_id * parameter, so determine that
> explicitly in the probe function.
> 
> Signed-off-by: Uwe Kleine-König 

Acked-by: Michael Hennerich 

> ---
>  drivers/video/backlight/adp8860_bl.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/backlight/adp8860_bl.c
> b/drivers/video/backlight/adp8860_bl.c
> index b0fe02273e87..a479aab90f78 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -648,9 +648,9 @@ static const struct attribute_group
> adp8860_bl_attr_group = {
>   .attrs = adp8860_bl_attributes,
>  };
> 
> -static int adp8860_probe(struct i2c_client *client,
> - const struct i2c_device_id *id)
> +static int adp8860_probe(struct i2c_client *client)
>  {
> + const struct i2c_device_id *id = i2c_client_get_device_id(client);
>   struct backlight_device *bl;
>   struct adp8860_bl *data;
>   struct adp8860_backlight_platform_data *pdata = @@ -803,7 +803,7
> @@ static struct i2c_driver adp8860_driver = {
>   .name   = KBUILD_MODNAME,
>   .pm = &adp8860_i2c_pm_ops,
>   },
> - .probe= adp8860_probe,
> + .probe_new = adp8860_probe,
>   .remove   = adp8860_remove,
>   .id_table = adp8860_id,
>  };
> --
> 2.38.1

Re: DRM-managed resources / devm_drm_dev_alloc leaking resources

[Stanislaw Gruszka]

Hi

On Sat, Nov 19, 2022 at 12:14:14PM +0100, Daniel Vetter wrote:
> On Fri, Nov 18, 2022 at 05:15:58PM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > Javier and I looked into it some more today, and I think we have a
> > better idea of what is going on.
> > 
> > On Thu, Nov 17, 2022 at 05:53:11PM +0100, Maxime Ripard wrote:
> > > After trying to get more kunit tests for KMS, I found out that the
> > > recent kunit helpers we merged to create a DRM device [1] are broken and
> > > won't free their device-managed and DRM-managed resources.
> > > 
> > > With some help from Thomas, we've dug into this and it turns out that if
> > > we allocate a device with root_device_register, initialise our drm
> > > device with devm_drm_dev_alloc(), register it using drm_dev_register(),
> > > unregister it using drm_dev_unregister/drm_dev_unplug and then remove
> > > the parent device, neither the device managed nor the DRM managed
> > > actions are run.
> > > 
> > > root_device_register initializes the device by eventually calling
> > > device_initialize() which sets the initial reference count of the root
> > > device to 1 [2]. devm_drm_dev_alloc() then comes in, drm_dev_init() will
> > > increase the root device refcount [3] and initialize our DRM device to 1
> > > [4]. drm_dev_register(), through drm_minor_register() and device_add(),
> > > will increase the root device refcount [5].
> > > 
> > > When unrolling things, drm_dev_unregister(), through
> > > drm_minor_unregister() and device_del(), will give up its reference [6].
> > > root_device_unregister(), through device_unregister(), will also give up
> > > its own [7].
> > > 
> > > So we end up with this for the reference counts:
> > > 
> > > ++-++
> > > | funcs  | root device | DRM device |
> > > ++-++
> > > | root_device_register   |   1 | N/A|
> > > | devm_drm_dev_alloc |   2 | 1  |
> > > | drm_dev_register   |   3 | 1  |
> > > | drm_dev_unregister |   2 | 1  |
> > > | root_device_unregister |   1 | 1  |
> > > ++-++
> > > 
> > > If we go back to the list of reference taken, the root device reference
> > > and the initial drm_device reference, both taken by devm_drm_dev_alloc()
> > > through drm_dev_init(), haven't been put back.
> > > 
> > > If we look at the drm_dev_init code(), we can see that it sets up a
> > > DRM-managed action [8] that will put back the device reference [9]. The
> > > DRM-managed code is executed by the drm_managed_cleanup() function, that
> > > is executed as part of a release hook [10] executed once we give up the
> > > final reference to the DRM device [11].
> > > 
> > > If we go back a little, the final reference to the DRM device is
> > > actually the initial one setup by devm_drm_dev_alloc(). This function
> > > has superseded drm_dev_alloc(), with the documentation that we do need a
> > > final drm_dev_put() to put back our final reference [12].
> > > 
> > > devm_drm_dev_alloc() is a more convenient variant that has been
> > > introduced explicitly to not require that drm_dev_put(), and states it
> > > as such in the documentation [13]. It does so by adding a device-managed
> > > action that will call drm_dev_put() [14].
> > > 
> > > Device-managed actions are ran as part devres_release_all() that is
> > > called by device_release() [15], itself being run when the last
> > > reference on the device is put back [16][17][18].
> > > 
> > > So if we sum things up, the DRM device will only give its last root
> > > device reference when the last DRM device reference will be put back,
> > > and the last DRM device reference will be put back when the last device
> > > reference will be put back, which sounds very circular to me, with both
> > > ending up in a deadlock scenario.
> > > 
> > > I've added two kunit tests that demonstrate the issue: we register a
> > > device, allocate and register a DRM device, register a DRM-managed
> > > action, remove the DRM device and the parent device, and wait for the
> > > action to execute. drm_register_unregister_with_devm_test() uses the
> > > broken(?) devm_drm_dev_alloc and is failing.
> > > drm_register_unregister_test uses the deprecated drm_dev_alloc() that
> > > requires an explicit call to drm_dev_put() which works fine.
> > > 
> > > It's also worth noting that Thomas tested with simpledrm and it seems to
> > > work fine.
> > 
> > Indeed, the transition from simpledrm to a full-blown DRM driver handles
> > this properly. It's using a platform_device_unregister() [1] and
> > eventually device_del() [2][3]. That part is handled just like
> > root_device_unregister() [4][5]. Basically, both will call device_del(),
> > and then device_put(), so device_del() is called while holding a
> > reference.
> > 
> > As we've seen before, at this point the DRM dri

Re: [PATCH 585/606] backlight: adp8860: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:19PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> .probe_new() doesn't get the i2c_device_id * parameter, so determine
> that explicitly in the probe function.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 586/606] backlight: adp8870: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:20PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> .probe_new() doesn't get the i2c_device_id * parameter, so determine
> that explicitly in the probe function.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Andrzej Hajda]

On 21.11.2022 09:30, Janusz Krzysztofik wrote:

Hi Nimroy,

Thanks for looking at this.

On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:

On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:

Users of intel_gt_retire_requests_timeout() expect 0 return value on
success.  However, we have no protection from passing back 0 potentially
returned by a call to dma_fence_wait_timeout() when it succedes right
after its timeout has expired.

Replace 0 with -ETIME before potentially using the timeout value as return
code, so -ETIME is returned if there are still some requests not retired
after timeout, 0 otherwise.

v2: Move the added lines down so flush_submission() is not affected.

Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with

retire_request")

Signed-off-by: Janusz Krzysztofik 
Cc: sta...@vger.kernel.org # v5.5+
---
   drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
   1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/

drm/i915/gt/intel_gt_requests.c

index edb881d756309..3ac4603eeb4ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -199,6 +199,9 @@ out_active: spin_lock(&timelines->lock);
if (remaining_timeout)
*remaining_timeout = timeout;
   
+	if (!timeout)

+   timeout = -ETIME;

This will return error, -ETIME when 0 timeout is passed,
intel_gt_retire_requests().

Yes, but only when active_count is not 0 after we loop through
timelines->active_list calling retire_requests() on each and counting up
failures in active_count.


Moving this line just after the call to dma_fence_wait_timeout should 
solve the controversy.


Regards
Andrzej




We don't want that.

When 0 timeout is passed to intel_gt_retire_requests(), do we really want it
to return 0 unconditionally, or are we rather interested if those calls to
retire_requests() succeeded?


I think you can use a separate variable to store
return val from the dma_fence_wait_timeout()


Regards,

Nirmoy


+
return active_count ? timeout : 0;

If active count is 0, we return 0 regardless of timeout value, and that's OK.
However, if active_count is not 0, we shouldn't return 0, I believe, we should
return either remaining time if some left, or error (-ETIME) if not.  If you
think I'm wrong, please explain why.

Thanks,
Janusz


   }
   

Re: The state of Quantization Range handling

[Pekka Paalanen]

On Fri, 18 Nov 2022 15:53:29 +
Dave Stevenson  wrote:

> Hi Pekka
> 
> On Fri, 18 Nov 2022 at 10:15, Pekka Paalanen  wrote:
> >
> > On Thu, 17 Nov 2022 22:13:26 +0100
> > Sebastian Wick  wrote:
> >  
> > > Hi Dave,
> > >
> > > I noticed that I didn't get the Broadcast RGB property thanks to you
> > > (more below)
> > >
> > > On Tue, Nov 15, 2022 at 2:16 PM Dave Stevenson
> > >  wrote:  
> > > >
> > > > Hi Sebastian
> > > >
> > > > Thanks for starting the conversation - it's stalled a number of times
> > > > previously.
> > > >
> > > > On Mon, 14 Nov 2022 at 23:12, Sebastian Wick 
> > > >  wrote:  
> > > > >
> > > > > There are still regular bug reports about monitors (sinks) and sources
> > > > > disagreeing about the quantization range of the pixel data. In
> > > > > particular sources sending full range data when the sink expects
> > > > > limited range. From a user space perspective, this is all hidden in
> > > > > the kernel. We send full range data to the kernel and then hope it
> > > > > does the right thing but as the bug reports show: some combinations of
> > > > > displays and drivers result in problems.  
> > > >
> > > > I'll agree that we as Raspberry Pi also get a number of bug reports
> > > > where sinks don't always look at the infoframes and misinterpret the
> > > > data.
> > > >  
> > > > > In general the whole handling of the quantization range on linux is
> > > > > not defined or documented at all. User space sends full range data
> > > > > because that's what seems to work most of the time but technically
> > > > > this is all undefined and user space can not fix those issues. Some
> > > > > compositors have resorted to giving users the option to choose the
> > > > > quantization range but this really should only be necessary for
> > > > > straight up broken hardware.  
> > > >
> > > > Wowsers! Making userspace worry about limited range data would be a
> > > > very weird decision in my view, so compositors should always deal in
> > > > full range data.  
> > >
> > > Making this a user space problem is IMO the ideal way to deal with it
> > > but that's a bit harder to do (I'll answer that in the reply to
> > > Pekka). So let's just assume we all agree that user space only deals
> > > with full range data.  
> >
> > Limited range was invented for some reason, so it must have some use
> > somewhere, at least in the past. Maybe it was needed to calibrate mixed
> > digital/analog video processing chains with test images that needed to
> > contain sub-blacks and super-whites, to make sure that sub-blacks come
> > out as the nominal black etc. Just because desktop computers do not
> > seem to have any need for limited range, I personally wouldn't be as
> > arrogant as to say it's never useful. Maybe there are professional
> > video/broadcasting needs that currently can only be realized with
> > proprietary OS/hardware, because Linux just can't do it today?
> >
> > Why would TVs support limited range, if it was never useful? Why would
> > video sources produce limited range if it was always strictly inferior
> > to full range?
> >
> > Even digital image processing algorithms might make use of
> > out-of-unit-range values, not just analog circuitry for overshoot.
> >
> > But no, I can't give a real example, just speculation. Hence it's fine
> > by me to discard limited range processing for now. Still, what I
> > explain below would allow limited range processing without any extra
> > complexity by making the KMS color pipeline better defined and less
> > limiting for userspace.  
> 
> AIUI limited range comes from the analogue world, or possibly creative
> (film/TV) world, hence being used on Consumer devices rather than IT
> ones (CTA and CEA modes vs VESA and DMT modes).
> 
> YCbCr output from video codecs typically uses a range of 16-235,
> therefore a media player wanting to pass the decoded video out to the
> display exactly as-is needs to be able to signal that to the display
> for it to be interpreted correctly.
> 
> HDMI extended DVI. I believe both YCbCr support and range control were
> added to the HDMI spec at the same time, presumably to allow for this
> use case. Limited range RGB seems to be a bit of a quirk though.
> 
> Just to be annoying, JPEG uses full range YCbCr.
> 
> > > > How would composition of multiple DRM planes work if some are limited
> > > > range and some are full but you want limited range output? Your
> > > > hardware needs to have CSC matrices to convert full range down to
> > > > limited range, and know that you want to use them to effectively
> > > > compose to limited range.
> > > > In fact you can't currently tell DRM that an RGB plane is limited
> > > > range - the values in enum drm_color_range are
> > > > DRM_COLOR_YCBCR_LIMITED_RANGE and DRM_COLOR_YCBCR_FULL_RANGE [1].  
> >
> > Yeah, that's because range conversion has been conflated with
> > YUV-to-RGB conversion, and the result is always full-range RGB in
> > practise, AFAIU. There is no way to feed

Re: [PATCH 587/606] backlight: arcxcnn: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:21PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

[PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Thomas Zimmermann]

Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
drivers vmap/vunmap GEM buffer memory during the atomic commit.
Shadow-plane helpers automate this process.

Patches 1 to 4 prepare the MIPI code for the change and simplify
the restof the patchset.

Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
shadow-plane helpers. Most of the affected drivers call MIPI-DBI
helpers and get the update automatically. Only ili9225 and st7586
require changes to their source code.

Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
needed, but streamlines the driver code and make sense overall.

Testing is welcome, as I don't have any hardware to test these
changes myself.

Thomas Zimmermann (8):
  drm/simple-kms: Remove drm_gem_simple_display_pipe_prepare_fb()
  drm/ili9225: Call MIPI DBI mode_valid helper
  drm/st7586: Call MIPI DBI mode_valid helper
  drm/mipi-dbi: Initialize default driver functions with macro
  drm/mipi-dbi: Prepare framebuffer copy operation in pipe-update
helpers
  drm/mipi-dbi: Support shadow-plane state
  drm/mipi-dbi: Use shadow-plane mappings
  drm/mipi-dbi: Move drm_dev_{enter,exit}() out from fb_dirty functions

 drivers/gpu/drm/drm_gem_atomic_helper.c  |  31 +---
 drivers/gpu/drm/drm_mipi_dbi.c   | 175 +++
 drivers/gpu/drm/drm_simple_kms_helper.c  |   2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c |   6 +-
 drivers/gpu/drm/tiny/hx8357d.c   |   5 +-
 drivers/gpu/drm/tiny/ili9163.c   |   6 +-
 drivers/gpu/drm/tiny/ili9225.c   |  42 +++--
 drivers/gpu/drm/tiny/ili9341.c   |   5 +-
 drivers/gpu/drm/tiny/ili9486.c   |   5 +-
 drivers/gpu/drm/tiny/mi0283qt.c  |   5 +-
 drivers/gpu/drm/tiny/panel-mipi-dbi.c|   5 +-
 drivers/gpu/drm/tiny/st7586.c|  45 +++--
 drivers/gpu/drm/tiny/st7735r.c   |   5 +-
 include/drm/drm_gem_atomic_helper.h  |   2 -
 include/drm/drm_mipi_dbi.h   |  50 +-
 include/drm/drm_plane.h  |   4 +-
 include/drm/drm_simple_kms_helper.h  |   4 +-
 17 files changed, 265 insertions(+), 132 deletions(-)


base-commit: b7598e2b3a3116bb5ddbf756db30a0e5dc0877ea
prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
prerequisite-patch-id: 3f204510fcbf9530d6540bd8e6128cce598988b6
-- 
2.38.1

[PATCH 4/8] drm/mipi-dbi: Initialize default driver functions with macro

[Thomas Zimmermann]

Introduce DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS to initialize MIPI-DBI
helpers to default values and convert drivers. The prepare_fb function
set by some drivers is called implicitly by simple-kms helpers, so leave
it out.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c |  5 +
 drivers/gpu/drm/tiny/hx8357d.c   |  5 +
 drivers/gpu/drm/tiny/ili9163.c   |  5 +
 drivers/gpu/drm/tiny/ili9341.c   |  5 +
 drivers/gpu/drm/tiny/ili9486.c   |  5 +
 drivers/gpu/drm/tiny/mi0283qt.c  |  5 +
 drivers/gpu/drm/tiny/panel-mipi-dbi.c|  5 +
 drivers/gpu/drm/tiny/st7735r.c   |  5 +
 include/drm/drm_mipi_dbi.h   | 16 
 9 files changed, 24 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index be088983aa7c7..3fdf884b3257f 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -577,10 +577,7 @@ static void ili9341_dbi_enable(struct 
drm_simple_display_pipe *pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs ili9341_dbi_funcs = {
-   .mode_valid = mipi_dbi_pipe_mode_valid,
-   .enable = ili9341_dbi_enable,
-   .disable = mipi_dbi_pipe_disable,
-   .update = mipi_dbi_pipe_update,
+   DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(ili9341_dbi_enable),
 };
 
 static const struct drm_display_mode ili9341_dbi_mode = {
diff --git a/drivers/gpu/drm/tiny/hx8357d.c b/drivers/gpu/drm/tiny/hx8357d.c
index 9f634f720817b..cdc4486e059b5 100644
--- a/drivers/gpu/drm/tiny/hx8357d.c
+++ b/drivers/gpu/drm/tiny/hx8357d.c
@@ -181,10 +181,7 @@ static void yx240qv29_enable(struct 
drm_simple_display_pipe *pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = {
-   .mode_valid = mipi_dbi_pipe_mode_valid,
-   .enable = yx240qv29_enable,
-   .disable = mipi_dbi_pipe_disable,
-   .update = mipi_dbi_pipe_update,
+   DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(yx240qv29_enable),
 };
 
 static const struct drm_display_mode yx350hv15_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
index 835ed12792d56..bc4384d410fcc 100644
--- a/drivers/gpu/drm/tiny/ili9163.c
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -100,10 +100,7 @@ static void yx240qv29_enable(struct 
drm_simple_display_pipe *pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs ili9163_pipe_funcs = {
-   .mode_valid = mipi_dbi_pipe_mode_valid,
-   .enable = yx240qv29_enable,
-   .disable = mipi_dbi_pipe_disable,
-   .update = mipi_dbi_pipe_update,
+   DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(yx240qv29_enable),
 };
 
 static const struct drm_display_mode yx240qv29_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9341.c b/drivers/gpu/drm/tiny/ili9341.c
index 420f6005a9568..47b61c3bf1457 100644
--- a/drivers/gpu/drm/tiny/ili9341.c
+++ b/drivers/gpu/drm/tiny/ili9341.c
@@ -137,10 +137,7 @@ static void yx240qv29_enable(struct 
drm_simple_display_pipe *pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs ili9341_pipe_funcs = {
-   .mode_valid = mipi_dbi_pipe_mode_valid,
-   .enable = yx240qv29_enable,
-   .disable = mipi_dbi_pipe_disable,
-   .update = mipi_dbi_pipe_update,
+   DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(yx240qv29_enable),
 };
 
 static const struct drm_display_mode yx240qv29_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 1bb847466b107..9f735d84d85d4 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -150,10 +150,7 @@ static void waveshare_enable(struct 
drm_simple_display_pipe *pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs waveshare_pipe_funcs = {
-   .mode_valid = mipi_dbi_pipe_mode_valid,
-   .enable = waveshare_enable,
-   .disable = mipi_dbi_pipe_disable,
-   .update = mipi_dbi_pipe_update,
+   DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(waveshare_enable),
 };
 
 static const struct drm_display_mode waveshare_mode = {
diff --git a/drivers/gpu/drm/tiny/mi0283qt.c b/drivers/gpu/drm/tiny/mi0283qt.c
index 47df2b5a3048f..01ff43c8ac3ff 100644
--- a/drivers/gpu/drm/tiny/mi0283qt.c
+++ b/drivers/gpu/drm/tiny/mi0283qt.c
@@ -141,10 +141,7 @@ static void mi0283qt_enable(struct drm_simple_display_pipe 
*pipe,
 }
 
 static const struct drm_simple_display_pipe_funcs mi0283qt_pipe_funcs = {
-   .mode_valid = mipi_dbi_pipe_mode_valid,
-   .enable = mi0283qt_enable,
-   .disable = mipi_dbi_pipe_disable,
-   .update = mipi_dbi_pipe_update,
+   DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS(mi0283qt_enable),
 };
 
 static const struct drm_display_mode mi0283qt_mode = {
diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c 
b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
index 03a7d569cd568..2ed23ded51997 100644
--- a/drivers/gpu/drm/

[PATCH 5/8] drm/mipi-dbi: Prepare framebuffer copy operation in pipe-update helpers

[Thomas Zimmermann]

Move the vmap/vunmap blocks from the inner fb_dirty helpers into the
MIPI DBI update helpers. The function calls can result in waiting and/or
processing overhead. Reduce the penalties by executing the functions once
in the outer-most function of the pipe update.

This change also prepares for MIPI DBI for shadow-plane helpers. With
shadow-plane helpers, transfer source buffers are mapped into kernel
address space automatically.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 60 +++---
 drivers/gpu/drm/tiny/ili9225.c | 31 ++
 drivers/gpu/drm/tiny/st7586.c  | 28 +++-
 include/drm/drm_mipi_dbi.h |  6 ++--
 4 files changed, 81 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index a6ac565808765..40e59a3a6481e 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -192,6 +192,7 @@ EXPORT_SYMBOL(mipi_dbi_command_stackbuf);
 /**
  * mipi_dbi_buf_copy - Copy a framebuffer, transforming it if necessary
  * @dst: The destination buffer
+ * @src: The source buffer
  * @fb: The source framebuffer
  * @clip: Clipping rectangle of the area to be copied
  * @swap: When true, swap MSB/LSB of 16-bit values
@@ -199,12 +200,13 @@ EXPORT_SYMBOL(mipi_dbi_command_stackbuf);
  * Returns:
  * Zero on success, negative error code on failure.
  */
-int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
+int mipi_dbi_buf_copy(void *dst, struct iosys_map *src, struct drm_framebuffer 
*fb,
  struct drm_rect *clip, bool swap)
 {
struct drm_gem_object *gem = drm_gem_fb_get_obj(fb, 0);
-   struct iosys_map map[DRM_FORMAT_MAX_PLANES];
-   struct iosys_map data[DRM_FORMAT_MAX_PLANES];
+   struct iosys_map data[DRM_FORMAT_MAX_PLANES] = {
+   *src,
+   };
struct iosys_map dst_map = IOSYS_MAP_INIT_VADDR(dst);
int ret;
 
@@ -212,10 +214,6 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer 
*fb,
if (ret)
return ret;
 
-   ret = drm_gem_fb_vmap(fb, map, data);
-   if (ret)
-   goto out_drm_gem_fb_end_cpu_access;
-
switch (fb->format->format) {
case DRM_FORMAT_RGB565:
if (swap)
@@ -232,8 +230,6 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
ret = -EINVAL;
}
 
-   drm_gem_fb_vunmap(fb, map);
-out_drm_gem_fb_end_cpu_access:
drm_gem_fb_end_cpu_access(fb, DMA_FROM_DEVICE);
 
return ret;
@@ -257,10 +253,9 @@ static void mipi_dbi_set_window_address(struct 
mipi_dbi_dev *dbidev,
 ys & 0xff, (ye >> 8) & 0xff, ye & 0xff);
 }
 
-static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, struct drm_rect 
*rect)
+static void mipi_dbi_fb_dirty(struct iosys_map *src, struct drm_framebuffer 
*fb,
+ struct drm_rect *rect)
 {
-   struct iosys_map map[DRM_FORMAT_MAX_PLANES];
-   struct iosys_map data[DRM_FORMAT_MAX_PLANES];
struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
unsigned int height = rect->y2 - rect->y1;
unsigned int width = rect->x2 - rect->x1;
@@ -270,16 +265,9 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, 
struct drm_rect *rect)
bool full;
void *tr;
 
-   if (WARN_ON(!fb))
-   return;
-
if (!drm_dev_enter(fb->dev, &idx))
return;
 
-   ret = drm_gem_fb_vmap(fb, map, data);
-   if (ret)
-   goto err_drm_dev_exit;
-
full = width == fb->width && height == fb->height;
 
DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id, 
DRM_RECT_ARG(rect));
@@ -287,11 +275,11 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, 
struct drm_rect *rect)
if (!dbi->dc || !full || swap ||
fb->format->format == DRM_FORMAT_XRGB) {
tr = dbidev->tx_buf;
-   ret = mipi_dbi_buf_copy(dbidev->tx_buf, fb, rect, swap);
+   ret = mipi_dbi_buf_copy(tr, src, fb, rect, swap);
if (ret)
goto err_msg;
} else {
-   tr = data[0].vaddr; /* TODO: Use mapping abstraction properly */
+   tr = src->vaddr; /* TODO: Use mapping abstraction properly */
}
 
mipi_dbi_set_window_address(dbidev, rect->x1, rect->x2 - 1, rect->y1,
@@ -303,9 +291,6 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, 
struct drm_rect *rect)
if (ret)
drm_err_once(fb->dev, "Failed to update display %d\n", ret);
 
-   drm_gem_fb_vunmap(fb, map);
-
-err_drm_dev_exit:
drm_dev_exit(idx);
 }
 
@@ -338,14 +323,27 @@ EXPORT_SYMBOL(mipi_dbi_pipe_mode_valid);
 void mipi_dbi_pipe_update(struct drm_simple_display_pipe *pipe,
  struct drm_plane_state *old_state)
 {
+   struct iosys_map map[DRM_FORMAT_MAX_PLANES]

[PATCH 1/8] drm/simple-kms: Remove drm_gem_simple_display_pipe_prepare_fb()

[Thomas Zimmermann]

The helper drm_gem_simple_display_pipe_prepare_fb() is simple-KMS'
default implementation for prepare_fb. Remove the call from drivers
that set it explicitly. Then inline the helper into the only caller
within simple-kms helpers and remove . No functional changes.

Simple-KMS drivers that implement the prepare_fb callback should call
drm_gem_plane_helper_prepare_fb() directly.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_gem_atomic_helper.c  | 31 +---
 drivers/gpu/drm/drm_simple_kms_helper.c  |  2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c |  1 -
 drivers/gpu/drm/tiny/ili9163.c   |  1 -
 include/drm/drm_gem_atomic_helper.h  |  2 --
 include/drm/drm_plane.h  |  4 +--
 include/drm/drm_simple_kms_helper.h  |  4 +--
 7 files changed, 6 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_atomic_helper.c 
b/drivers/gpu/drm/drm_gem_atomic_helper.c
index e42800718f515..5d4b9cd077f7a 100644
--- a/drivers/gpu/drm/drm_gem_atomic_helper.c
+++ b/drivers/gpu/drm/drm_gem_atomic_helper.c
@@ -26,11 +26,8 @@
  * call drm_gem_plane_helper_prepare_fb() from their implementation of
  * struct &drm_plane_helper.prepare_fb . It sets the plane's fence from
  * the framebuffer so that the DRM core can synchronize access automatically.
- *
  * drm_gem_plane_helper_prepare_fb() can also be used directly as
- * implementation of prepare_fb. For drivers based on
- * struct drm_simple_display_pipe, drm_gem_simple_display_pipe_prepare_fb()
- * provides equivalent functionality.
+ * implementation of prepare_fb.
  *
  * .. code-block:: c
  *
@@ -41,11 +38,6 @@
  * . prepare_fb = drm_gem_plane_helper_prepare_fb,
  * };
  *
- * struct drm_simple_display_pipe_funcs driver_pipe_funcs = {
- * ...,
- * . prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
- * };
- *
  * A driver using a shadow buffer copies the content of the shadow buffers
  * into the HW's framebuffer memory during an atomic update. This requires
  * a mapping of the shadow buffer into kernel address space. The mappings
@@ -205,27 +197,6 @@ int drm_gem_plane_helper_prepare_fb(struct drm_plane 
*plane,
 }
 EXPORT_SYMBOL_GPL(drm_gem_plane_helper_prepare_fb);
 
-/**
- * drm_gem_simple_display_pipe_prepare_fb - prepare_fb helper for 
&drm_simple_display_pipe
- * @pipe: Simple display pipe
- * @plane_state: Plane state
- *
- * This function uses drm_gem_plane_helper_prepare_fb() to extract the fences
- * from &drm_gem_object.resv and attaches them to the plane state for the 
atomic
- * helper to wait on. This is necessary to correctly implement implicit
- * synchronization for any buffers shared as a struct &dma_buf. Drivers can use
- * this as their &drm_simple_display_pipe_funcs.prepare_fb callback.
- *
- * See drm_gem_plane_helper_prepare_fb() for a discussion of implicit and
- * explicit fencing in atomic modeset updates.
- */
-int drm_gem_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe 
*pipe,
-  struct drm_plane_state *plane_state)
-{
-   return drm_gem_plane_helper_prepare_fb(&pipe->plane, plane_state);
-}
-EXPORT_SYMBOL(drm_gem_simple_display_pipe_prepare_fb);
-
 /*
  * Shadow-buffered Planes
  */
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 3ef420ec4534a..270523ae36d43 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -267,7 +267,7 @@ static int drm_simple_kms_plane_prepare_fb(struct drm_plane 
*plane,
 
WARN_ON_ONCE(pipe->funcs && pipe->funcs->cleanup_fb);
 
-   return drm_gem_simple_display_pipe_prepare_fb(pipe, state);
+   return drm_gem_plane_helper_prepare_fb(plane, state);
}
 
return pipe->funcs->prepare_fb(pipe, state);
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 384a724f2822e..be088983aa7c7 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -581,7 +581,6 @@ static const struct drm_simple_display_pipe_funcs 
ili9341_dbi_funcs = {
.enable = ili9341_dbi_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
-   .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
 };
 
 static const struct drm_display_mode ili9341_dbi_mode = {
diff --git a/drivers/gpu/drm/tiny/ili9163.c b/drivers/gpu/drm/tiny/ili9163.c
index ca0451f799625..835ed12792d56 100644
--- a/drivers/gpu/drm/tiny/ili9163.c
+++ b/drivers/gpu/drm/tiny/ili9163.c
@@ -104,7 +104,6 @@ static const struct drm_simple_display_pipe_funcs 
ili9163_pipe_funcs = {
.enable = yx240qv29_enable,
.disable = mipi_dbi_pipe_disable,
.update = mipi_dbi_pipe_update,
-   .prepare_fb = drm_gem_simple_display_pipe_prepare_fb,
 };
 
 static const struct drm_di

[PATCH 7/8] drm/mipi-dbi: Use shadow-plane mappings

[Thomas Zimmermann]

Use the buffer mappings provided by shadow-plane helpers. As the
mappings are established while the commit can still fail, errors
are now reported correctly to callers.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 31 +++
 drivers/gpu/drm/tiny/ili9225.c | 28 ++--
 drivers/gpu/drm/tiny/st7586.c  | 22 ++
 3 files changed, 31 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 3030344d25b48..d45824a65c9fd 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -323,12 +323,13 @@ EXPORT_SYMBOL(mipi_dbi_pipe_mode_valid);
 void mipi_dbi_pipe_update(struct drm_simple_display_pipe *pipe,
  struct drm_plane_state *old_state)
 {
-   struct iosys_map map[DRM_FORMAT_MAX_PLANES];
-   struct iosys_map data[DRM_FORMAT_MAX_PLANES];
struct drm_plane_state *state = pipe->plane.state;
+   struct mipi_dbi_plane_state *mipi_dbi_plane_state =
+   to_mipi_dbi_plane_state(state);
+   struct drm_shadow_plane_state *shadow_plane_state =
+   &mipi_dbi_plane_state->shadow_plane_state;
struct drm_framebuffer *fb = state->fb;
struct drm_rect rect;
-   int ret;
 
if (!pipe->crtc.state->active)
return;
@@ -336,14 +337,8 @@ void mipi_dbi_pipe_update(struct drm_simple_display_pipe 
*pipe,
if (WARN_ON(!fb))
return;
 
-   ret = drm_gem_fb_vmap(fb, map, data);
-   if (ret)
-   return;
-
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
-   mipi_dbi_fb_dirty(&data[0], fb, &rect);
-
-   drm_gem_fb_vunmap(fb, map);
+   mipi_dbi_fb_dirty(&shadow_plane_state->data[0], fb, &rect);
 }
 EXPORT_SYMBOL(mipi_dbi_pipe_update);
 
@@ -364,6 +359,10 @@ void mipi_dbi_enable_flush(struct mipi_dbi_dev *dbidev,
   struct drm_crtc_state *crtc_state,
   struct drm_plane_state *plane_state)
 {
+   struct mipi_dbi_plane_state *mipi_dbi_plane_state =
+   to_mipi_dbi_plane_state(plane_state);
+   struct drm_shadow_plane_state *shadow_plane_state =
+   &mipi_dbi_plane_state->shadow_plane_state;
struct drm_framebuffer *fb = plane_state->fb;
struct drm_rect rect = {
.x1 = 0,
@@ -371,22 +370,14 @@ void mipi_dbi_enable_flush(struct mipi_dbi_dev *dbidev,
.y1 = 0,
.y2 = fb->height,
};
-   struct iosys_map map[DRM_FORMAT_MAX_PLANES];
-   struct iosys_map data[DRM_FORMAT_MAX_PLANES];
-   int idx, ret;
+   int idx;
 
if (!drm_dev_enter(&dbidev->drm, &idx))
return;
 
-   ret = drm_gem_fb_vmap(fb, map, data);
-   if (ret)
-   goto err_drm_dev_exit;
-
-   mipi_dbi_fb_dirty(&data[0], fb, &rect);
+   mipi_dbi_fb_dirty(&shadow_plane_state->data[0], fb, &rect);
backlight_enable(dbidev->backlight);
 
-   drm_gem_fb_vunmap(fb, map);
-err_drm_dev_exit:
drm_dev_exit(idx);
 }
 EXPORT_SYMBOL(mipi_dbi_enable_flush);
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index 9e55ce28b4552..ba5681b63ffbf 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -163,24 +163,19 @@ static void ili9225_fb_dirty(struct iosys_map *src, 
struct drm_framebuffer *fb,
 static void ili9225_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *old_state)
 {
-   struct iosys_map map[DRM_FORMAT_MAX_PLANES];
-   struct iosys_map data[DRM_FORMAT_MAX_PLANES];
struct drm_plane_state *state = pipe->plane.state;
+   struct mipi_dbi_plane_state *mipi_dbi_plane_state =
+   to_mipi_dbi_plane_state(state);
+   struct drm_shadow_plane_state *shadow_plane_state =
+   &mipi_dbi_plane_state->shadow_plane_state;
struct drm_framebuffer *fb = state->fb;
struct drm_rect rect;
-   int ret;
 
if (!pipe->crtc.state->active)
return;
 
-   ret = drm_gem_fb_vmap(fb, map, data);
-   if (ret)
-   return;
-
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
-   ili9225_fb_dirty(&data[0], fb, &rect);
-
-   drm_gem_fb_vunmap(fb, map);
+   ili9225_fb_dirty(&shadow_plane_state->data[0], fb, &rect);
 }
 
 static void ili9225_pipe_enable(struct drm_simple_display_pipe *pipe,
@@ -188,6 +183,10 @@ static void ili9225_pipe_enable(struct 
drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
 {
struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(pipe->crtc.dev);
+   struct mipi_dbi_plane_state *mipi_dbi_plane_state =
+   to_mipi_dbi_plane_state(plane_state);
+   struct drm_shadow_plane_sta

[PATCH 8/8] drm/mipi-dbi: Move drm_dev_{enter, exit}() out from fb_dirty functions

[Thomas Zimmermann]

Call drm_dev_enter() and drm_dev_exit() in the outer-most callbacks
of the modesetting pipeline. If drm_dev_enter() fails, the driver can
thus avoid unnecessary work.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 13 +++--
 drivers/gpu/drm/tiny/ili9225.c | 13 +++--
 drivers/gpu/drm/tiny/st7586.c  | 13 +++--
 3 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index d45824a65c9fd..fc1c8c536370a 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -261,13 +261,10 @@ static void mipi_dbi_fb_dirty(struct iosys_map *src, 
struct drm_framebuffer *fb,
unsigned int width = rect->x2 - rect->x1;
struct mipi_dbi *dbi = &dbidev->dbi;
bool swap = dbi->swap_bytes;
-   int idx, ret = 0;
+   int ret = 0;
bool full;
void *tr;
 
-   if (!drm_dev_enter(fb->dev, &idx))
-   return;
-
full = width == fb->width && height == fb->height;
 
DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id, 
DRM_RECT_ARG(rect));
@@ -290,8 +287,6 @@ static void mipi_dbi_fb_dirty(struct iosys_map *src, struct 
drm_framebuffer *fb,
 err_msg:
if (ret)
drm_err_once(fb->dev, "Failed to update display %d\n", ret);
-
-   drm_dev_exit(idx);
 }
 
 /**
@@ -330,6 +325,7 @@ void mipi_dbi_pipe_update(struct drm_simple_display_pipe 
*pipe,
&mipi_dbi_plane_state->shadow_plane_state;
struct drm_framebuffer *fb = state->fb;
struct drm_rect rect;
+   int idx;
 
if (!pipe->crtc.state->active)
return;
@@ -337,8 +333,13 @@ void mipi_dbi_pipe_update(struct drm_simple_display_pipe 
*pipe,
if (WARN_ON(!fb))
return;
 
+   if (!drm_dev_enter(fb->dev, &idx))
+   return;
+
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
mipi_dbi_fb_dirty(&shadow_plane_state->data[0], fb, &rect);
+
+   drm_dev_exit(idx);
 }
 EXPORT_SYMBOL(mipi_dbi_pipe_update);
 
diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index ba5681b63ffbf..7ecbb8b141757 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -87,13 +87,10 @@ static void ili9225_fb_dirty(struct iosys_map *src, struct 
drm_framebuffer *fb,
bool swap = dbi->swap_bytes;
u16 x_start, y_start;
u16 x1, x2, y1, y2;
-   int idx, ret = 0;
+   int ret = 0;
bool full;
void *tr;
 
-   if (!drm_dev_enter(fb->dev, &idx))
-   return;
-
full = width == fb->width && height == fb->height;
 
DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id, 
DRM_RECT_ARG(rect));
@@ -156,8 +153,6 @@ static void ili9225_fb_dirty(struct iosys_map *src, struct 
drm_framebuffer *fb,
 err_msg:
if (ret)
dev_err_once(fb->dev->dev, "Failed to update display %d\n", 
ret);
-
-   drm_dev_exit(idx);
 }
 
 static void ili9225_pipe_update(struct drm_simple_display_pipe *pipe,
@@ -170,12 +165,18 @@ static void ili9225_pipe_update(struct 
drm_simple_display_pipe *pipe,
&mipi_dbi_plane_state->shadow_plane_state;
struct drm_framebuffer *fb = state->fb;
struct drm_rect rect;
+   int idx;
 
if (!pipe->crtc.state->active)
return;
 
+   if (!drm_dev_enter(fb->dev, &idx))
+   return;
+
if (drm_atomic_helper_damage_merged(old_state, state, &rect))
ili9225_fb_dirty(&shadow_plane_state->data[0], fb, &rect);
+
+   drm_dev_exit(idx);
 }
 
 static void ili9225_pipe_enable(struct drm_simple_display_pipe *pipe,
diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
index ddaa82c2e58ae..0f5e532fe5d1d 100644
--- a/drivers/gpu/drm/tiny/st7586.c
+++ b/drivers/gpu/drm/tiny/st7586.c
@@ -113,10 +113,7 @@ static void st7586_fb_dirty(struct iosys_map *src, struct 
drm_framebuffer *fb,
 {
struct mipi_dbi_dev *dbidev = drm_to_mipi_dbi_dev(fb->dev);
struct mipi_dbi *dbi = &dbidev->dbi;
-   int start, end, idx, ret = 0;
-
-   if (!drm_dev_enter(fb->dev, &idx))
-   return;
+   int start, end, ret = 0;
 
/* 3 pixels per byte, so grow clip to nearest multiple of 3 */
rect->x1 = rounddown(rect->x1, 3);
@@ -145,8 +142,6 @@ static void st7586_fb_dirty(struct iosys_map *src, struct 
drm_framebuffer *fb,
 err_msg:
if (ret)
dev_err_once(fb->dev->dev, "Failed to update display %d\n", 
ret);
-
-   drm_dev_exit(idx);
 }
 
 static void st7586_pipe_update(struct drm_simple_display_pipe *pipe,
@@ -159,12 +154,18 @@ static void st7586_pipe_update(struct 
drm_simple_display_pipe *pipe,
&mipi_dbi_plane_state->shadow_plane_state;
struct drm_framebuffer *fb = state->fb;
struct drm_rect rect;
+   int idx;

[PATCH 2/8] drm/ili9225: Call MIPI DBI mode_valid helper

[Thomas Zimmermann]

MIPI DBI drivers validate each mode against their native resolution.
Add this test to ili9225.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tiny/ili9225.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tiny/ili9225.c b/drivers/gpu/drm/tiny/ili9225.c
index 815bab2858231..f05a2d25866c1 100644
--- a/drivers/gpu/drm/tiny/ili9225.c
+++ b/drivers/gpu/drm/tiny/ili9225.c
@@ -326,6 +326,7 @@ static int ili9225_dbi_command(struct mipi_dbi *dbi, u8 
*cmd, u8 *par,
 }
 
 static const struct drm_simple_display_pipe_funcs ili9225_pipe_funcs = {
+   .mode_valid = mipi_dbi_pipe_mode_valid,
.enable = ili9225_pipe_enable,
.disable= ili9225_pipe_disable,
.update = ili9225_pipe_update,
-- 
2.38.1

[PATCH 3/8] drm/st7586: Call MIPI DBI mode_valid helper

[Thomas Zimmermann]

MIPI DBI drivers validate each mode against their native resolution.
Add this test to st7586.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tiny/st7586.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tiny/st7586.c b/drivers/gpu/drm/tiny/st7586.c
index ce57fa9917e51..6bdd23e2a47c7 100644
--- a/drivers/gpu/drm/tiny/st7586.c
+++ b/drivers/gpu/drm/tiny/st7586.c
@@ -263,6 +263,7 @@ static const u32 st7586_formats[] = {
 };
 
 static const struct drm_simple_display_pipe_funcs st7586_pipe_funcs = {
+   .mode_valid = mipi_dbi_pipe_mode_valid,
.enable = st7586_pipe_enable,
.disable= st7586_pipe_disable,
.update = st7586_pipe_update,
-- 
2.38.1

[PATCH 6/8] drm/mipi-dbi: Support shadow-plane state

[Thomas Zimmermann]

Introduce struct drm_mipi_dbi_plane_state that contains state related to
MIPI DBI. It currently only inherits from struct drm_shadow_plane_state,
so that MIPI DBI drivers can use the vmap'ed GEM-buffer memory. Implement
state helpers, the {begin,end}_fb_access helpers and wire up everything.

With this commit, MIPI DBI drivers can access the GEM object's memory
that is provided by shadow-plane state. The actual changes to drivers
are implemented separately. The new struct drm_mipi_dbi_plane was added
to avoid exposing struct drm_shadow_plane_state directly. The latter is
a detail of the actual implementation and having it in the MIPI driver
interface seems unintuitive.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 113 +
 drivers/gpu/drm/tiny/ili9225.c |   5 ++
 drivers/gpu/drm/tiny/st7586.c  |   5 ++
 include/drm/drm_mipi_dbi.h |  30 -
 4 files changed, 152 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 40e59a3a6481e..3030344d25b48 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -436,6 +436,119 @@ void mipi_dbi_pipe_disable(struct drm_simple_display_pipe 
*pipe)
 }
 EXPORT_SYMBOL(mipi_dbi_pipe_disable);
 
+/**
+ * mipi_dbi_pipe_begin_fb_access - MIPI DBI pipe begin-access helper
+ * @pipe: Display pipe
+ * @plane_state: Plane state
+ *
+ * This function implements struct &drm_simple_display_funcs.begin_fb_access.
+ *
+ * See drm_gem_begin_shadow_fb_access() for details and 
mipi_dbi_pipe_cleanup_fb()
+ * for cleanup.
+ *
+ * Returns:
+ * 0 on success, or a negative errno code otherwise.
+ */
+int mipi_dbi_pipe_begin_fb_access(struct drm_simple_display_pipe *pipe,
+ struct drm_plane_state *plane_state)
+{
+   return drm_gem_begin_shadow_fb_access(&pipe->plane, plane_state);
+}
+EXPORT_SYMBOL(mipi_dbi_pipe_begin_fb_access);
+
+/**
+ * mipi_dbi_pipe_end_fb_access - MIPI DBI pipe end-access helper
+ * @pipe: Display pipe
+ * @plane_state: Plane state
+ *
+ * This function implements struct &drm_simple_display_funcs.end_fb_access.
+ *
+ * See mipi_dbi_pipe_begin_fb_access().
+ */
+void mipi_dbi_pipe_end_fb_access(struct drm_simple_display_pipe *pipe,
+struct drm_plane_state *plane_state)
+{
+   drm_gem_end_shadow_fb_access(&pipe->plane, plane_state);
+}
+EXPORT_SYMBOL(mipi_dbi_pipe_end_fb_access);
+
+/**
+ * mipi_dbi_pipe_reset_plane - MIPI DBI plane-reset helper
+ * @pipe: Display pipe
+ *
+ * This function implements struct &drm_simple_display_funcs.reset_plane
+ * for MIPI DBI planes.
+ */
+void mipi_dbi_pipe_reset_plane(struct drm_simple_display_pipe *pipe)
+{
+   struct drm_plane *plane = &pipe->plane;
+   struct mipi_dbi_plane_state *mipi_dbi_plane_state;
+
+   if (plane->state) {
+   mipi_dbi_pipe_destroy_plane_state(pipe, plane->state);
+   plane->state = NULL; /* must be set to NULL here */
+   }
+
+   mipi_dbi_plane_state = kzalloc(sizeof(*mipi_dbi_plane_state), 
GFP_KERNEL);
+   if (!mipi_dbi_plane_state)
+   return;
+   __drm_gem_reset_shadow_plane(plane, 
&mipi_dbi_plane_state->shadow_plane_state);
+}
+EXPORT_SYMBOL(mipi_dbi_pipe_reset_plane);
+
+/**
+ * mipi_dbi_pipe_duplicate_plane_state - duplicates MIPI DBI plane state
+ * @pipe: Display pipe
+ *
+ * This function implements struct 
&drm_simple_display_funcs.duplicate_plane_state
+ * for MIPI DBI planes.
+ *
+ * See drm_gem_duplicate_shadow_plane_state() for additional details.
+ *
+ * Returns:
+ * A pointer to a new plane state on success, or NULL otherwise.
+ */
+struct drm_plane_state *mipi_dbi_pipe_duplicate_plane_state(struct 
drm_simple_display_pipe *pipe)
+{
+   struct drm_plane *plane = &pipe->plane;
+   struct drm_plane_state *plane_state = plane->state;
+   struct mipi_dbi_plane_state *new_mipi_dbi_plane_state;
+   struct drm_shadow_plane_state *new_shadow_plane_state;
+
+   if (!plane_state)
+   return NULL;
+
+   new_mipi_dbi_plane_state = kzalloc(sizeof(*new_mipi_dbi_plane_state), 
GFP_KERNEL);
+   if (!new_mipi_dbi_plane_state)
+   return NULL;
+   new_shadow_plane_state = &new_mipi_dbi_plane_state->shadow_plane_state;
+
+   __drm_gem_duplicate_shadow_plane_state(plane, new_shadow_plane_state);
+
+   return &new_shadow_plane_state->base;
+}
+EXPORT_SYMBOL(mipi_dbi_pipe_duplicate_plane_state);
+
+/**
+ * mipi_dbi_pipe_destroy_plane_state - cleans up MIPI DBI plane state
+ * @pipe: Display pipe
+ * @plane_state: Plane state
+ *
+ * This function implements struct drm_simple_display_funcs.destroy_plane_state
+ * for MIPI DBI planes.
+ *
+ * See drm_gem_destroy_shadow_plane_state() for additional details.
+ */
+void mipi_dbi_pipe_destroy_plane_state(struct drm_simple_display_pipe *pipe,
+  struct drm_plane_state *plane_state)
+{
+   

Re: [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

Hi Andrzej,

Thanks for your comment.

On Monday, 21 November 2022 11:17:42 CET Andrzej Hajda wrote:
> 
> On 21.11.2022 09:30, Janusz Krzysztofik wrote:
> > Hi Nimroy,
> >
> > Thanks for looking at this.
> >
> > On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:
> >> On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:
> >>> Users of intel_gt_retire_requests_timeout() expect 0 return value on
> >>> success.  However, we have no protection from passing back 0 potentially
> >>> returned by a call to dma_fence_wait_timeout() when it succedes right
> >>> after its timeout has expired.
> >>>
> >>> Replace 0 with -ETIME before potentially using the timeout value as return
> >>> code, so -ETIME is returned if there are still some requests not retired
> >>> after timeout, 0 otherwise.
> >>>
> >>> v2: Move the added lines down so flush_submission() is not affected.
> >>>
> >>> Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with
> > retire_request")
> >>> Signed-off-by: Janusz Krzysztofik 
> >>> Cc: sta...@vger.kernel.org # v5.5+
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
> >>>1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/
> > drm/i915/gt/intel_gt_requests.c
> >>> index edb881d756309..3ac4603eeb4ee 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> >>> @@ -199,6 +199,9 @@ out_active:   spin_lock(&timelines->lock);
> >>>   if (remaining_timeout)
> >>>   *remaining_timeout = timeout;
> >>>
> >>> + if (!timeout)
> >>> + timeout = -ETIME;
> >> This will return error, -ETIME when 0 timeout is passed,
> >> intel_gt_retire_requests().
> > Yes, but only when active_count is not 0 after we loop through
> > timelines->active_list calling retire_requests() on each and counting up
> > failures in active_count.
> 
> Moving this line just after the call to dma_fence_wait_timeout should 
> solve the controversy.

But that would break our need to pass 0, not -ETIME, to flush_submission() in 
case the initial value of timeout was 0, as pointed out by Chris during our 
discussion on v2.

Maybe an inline comment above the added lines that explains why we are doing 
this could help?

Thanks,
Janusz

> 
> Regards
> Andrzej
> 
> >
> >> We don't want that.
> > When 0 timeout is passed to intel_gt_retire_requests(), do we really want it
> > to return 0 unconditionally, or are we rather interested if those calls to
> > retire_requests() succeeded?
> >
> >> I think you can use a separate variable to store
> >> return val from the dma_fence_wait_timeout()
> >>
> >>
> >> Regards,
> >>
> >> Nirmoy
> >>
> >>> +
> >>>   return active_count ? timeout : 0;
> > If active count is 0, we return 0 regardless of timeout value, and that's 
> > OK.
> > However, if active_count is not 0, we shouldn't return 0, I believe, we 
> > should
> > return either remaining time if some left, or error (-ETIME) if not.  If you
> > think I'm wrong, please explain why.
> >
> > Thanks,
> > Janusz
> >
> >>>}
> >>>
> >
> >
> >
> 
> 

Re: [PATCH v3 0/6] dt-bindings: Add macros for video interface bus types

[Sakari Ailus]

Hi Laurent,

On Sat, Nov 19, 2022 at 09:15:04PM +0200, Laurent Pinchart wrote:
> Hello,
> 
> On Fri, Nov 18, 2022 at 06:23:38PM +0900, Paul Elder wrote:
> > Hi Sakari,
> > 
> > Gentle ping.
> > 
> > On Sun, Jul 17, 2022 at 06:54:00AM +, Sakari Ailus wrote:
> > > Folks,
> > > 
> > > > Laurent Pinchart (6):
> > > >   dt-bindings: media: Add macros for video interface bus types
> > > >   dt-bindings: Use new video interface bus type macros in examples
> > > >   ARM: dts: freescale: Use new media bus type macros
> > > >   ARM: dts: omap: Use new media bus type macros
> > > >   ARM: dts: renesas: Use new media bus type macros
> > > >   ARM: dts: stm32: Use new media bus type macros
> > > 
> > > What's the preference on the tree through which these would be merged?
> > > 
> > > The two first should probably go through the media tree but what about the
> > > DTS? There's a dependency to the first patch. I can take these all if
> > > people are fine with that.
> > 
> > How is this going?
> 
> Sakari, if there's a concern taking patches 3/6 to 6/6 in the media
> tree, could you merge 1/6 and 2/6 ? If they can still be included in a
> pull request for v6.2, I'll work on getting the dts changes in v6.3
> through their respective trees.

I think I was expecting v4 from you. But I can address the comments, too,
they were minor matters.

For applying the DTS patches I'd like to have ack from respective
treemaintainers it's fine to take these through the media tree.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

On Monday, 21 November 2022 11:51:15 CET Janusz Krzysztofik wrote:
> Hi Andrzej,
> 
> Thanks for your comment.
> 
> On Monday, 21 November 2022 11:17:42 CET Andrzej Hajda wrote:
> > 
> > On 21.11.2022 09:30, Janusz Krzysztofik wrote:
> > > Hi Nimroy,
> > >
> > > Thanks for looking at this.
> > >
> > > On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:
> > >> On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:
> > >>> Users of intel_gt_retire_requests_timeout() expect 0 return value on
> > >>> success.  However, we have no protection from passing back 0 potentially
> > >>> returned by a call to dma_fence_wait_timeout() when it succedes right
> > >>> after its timeout has expired.
> > >>>
> > >>> Replace 0 with -ETIME before potentially using the timeout value as 
> > >>> return
> > >>> code, so -ETIME is returned if there are still some requests not retired
> > >>> after timeout, 0 otherwise.
> > >>>
> > >>> v2: Move the added lines down so flush_submission() is not affected.
> > >>>
> > >>> Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with
> > > retire_request")
> > >>> Signed-off-by: Janusz Krzysztofik 
> > >>> Cc: sta...@vger.kernel.org # v5.5+
> > >>> ---
> > >>>drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
> > >>>1 file changed, 3 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/
> > > drm/i915/gt/intel_gt_requests.c
> > >>> index edb881d756309..3ac4603eeb4ee 100644
> > >>> --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > >>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > >>> @@ -199,6 +199,9 @@ out_active: spin_lock(&timelines->lock);
> > >>> if (remaining_timeout)
> > >>> *remaining_timeout = timeout;
> > >>>
> > >>> +   if (!timeout)
> > >>> +   timeout = -ETIME;
> > >> This will return error, -ETIME when 0 timeout is passed,
> > >> intel_gt_retire_requests().
> > > Yes, but only when active_count is not 0 after we loop through
> > > timelines->active_list calling retire_requests() on each and counting up
> > > failures in active_count.
> > 
> > Moving this line just after the call to dma_fence_wait_timeout should 
> > solve the controversy.
> 
> But that would break our need to pass 0, not -ETIME, to flush_submission() in 
> case the initial value of timeout was 0, as pointed out by Chris during our 
> discussion on v2.
> 
> Maybe an inline comment above the added lines that explains why we are doing 
> this could help?

How about not adding those two lines but modifying the return line instead?

-   return active_count ? timeout : 0;
+   return active_count ? timeout ?: -ETIME : 0;

Would that be self explanatory?

Thanks,
Janusz

> 
> Thanks,
> Janusz
> 
> > 
> > Regards
> > Andrzej
> > 
> > >
> > >> We don't want that.
> > > When 0 timeout is passed to intel_gt_retire_requests(), do we really want 
> > > it
> > > to return 0 unconditionally, or are we rather interested if those calls to
> > > retire_requests() succeeded?
> > >
> > >> I think you can use a separate variable to store
> > >> return val from the dma_fence_wait_timeout()
> > >>
> > >>
> > >> Regards,
> > >>
> > >> Nirmoy
> > >>
> > >>> +
> > >>> return active_count ? timeout : 0;
> > > If active count is 0, we return 0 regardless of timeout value, and that's 
> > > OK.
> > > However, if active_count is not 0, we shouldn't return 0, I believe, we 
> > > should
> > > return either remaining time if some left, or error (-ETIME) if not.  If 
> > > you
> > > think I'm wrong, please explain why.
> > >
> > > Thanks,
> > > Janusz
> > >
> > >>>}
> > >>>
> > >
> > >
> > >
> > 
> > 
> 
> 

Re: [PATCH 588/606] backlight: bd6107: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:22PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 589/606] backlight: lm3630a: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:23PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH v3 0/6] dt-bindings: Add macros for video interface bus types

[Laurent Pinchart]

Hi Sakari,

On Mon, Nov 21, 2022 at 10:54:01AM +, Sakari Ailus wrote:
> On Sat, Nov 19, 2022 at 09:15:04PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 18, 2022 at 06:23:38PM +0900, Paul Elder wrote:
> > > On Sun, Jul 17, 2022 at 06:54:00AM +, Sakari Ailus wrote:
> > > > Folks,
> > > > 
> > > > > Laurent Pinchart (6):
> > > > >   dt-bindings: media: Add macros for video interface bus types
> > > > >   dt-bindings: Use new video interface bus type macros in examples
> > > > >   ARM: dts: freescale: Use new media bus type macros
> > > > >   ARM: dts: omap: Use new media bus type macros
> > > > >   ARM: dts: renesas: Use new media bus type macros
> > > > >   ARM: dts: stm32: Use new media bus type macros
> > > > 
> > > > What's the preference on the tree through which these would be merged?
> > > > 
> > > > The two first should probably go through the media tree but what about 
> > > > the
> > > > DTS? There's a dependency to the first patch. I can take these all if
> > > > people are fine with that.
> > > 
> > > How is this going?
> > 
> > Sakari, if there's a concern taking patches 3/6 to 6/6 in the media
> > tree, could you merge 1/6 and 2/6 ? If they can still be included in a
> > pull request for v6.2, I'll work on getting the dts changes in v6.3
> > through their respective trees.
> 
> I think I was expecting v4 from you. But I can address the comments, too,
> they were minor matters.

That would be nice :-) Could it still be done for v6.2 ?

> For applying the DTS patches I'd like to have ack from respective
> treemaintainers it's fine to take these through the media tree.

Works for me, this can be done in v6.3.

-- 
Regards,

Laurent Pinchart

Re: [PATCH AUTOSEL 6.0 38/44] drm/amdgpu: Unlock bo_list_mutex after error handling

[Christian König]

Am 21.11.22 um 10:57 schrieb Michel Dänzer:

On 11/19/22 03:11, Sasha Levin wrote:

From: Philip Yang 

[ Upstream commit 64f65135c41a75f933d3bca236417ad8e9eb75de ]

Get below kernel WARNING backtrace when pressing ctrl-C to kill kfdtest
application.

If amdgpu_cs_parser_bos returns error after taking bo_list_mutex, as
caller amdgpu_cs_ioctl will not unlock bo_list_mutex, this generates the
kernel WARNING.

Add unlock bo_list_mutex after amdgpu_cs_parser_bos error handling to
cleanup bo_list userptr bo.

  WARNING: kfdtest/2930 still has locks held!
  1 lock held by kfdtest/2930:
   (&list->bo_list_mutex){+.+.}-{3:3}, at: amdgpu_cs_ioctl+0xce5/0x1f10 [amdgpu]
   stack backtrace:
dump_stack_lvl+0x44/0x57
get_signal+0x79f/0xd00
arch_do_signal_or_restart+0x36/0x7b0
exit_to_user_mode_prepare+0xfd/0x1b0
syscall_exit_to_user_mode+0x19/0x40
do_syscall_64+0x40/0x80

Signed-off-by: Philip Yang 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index b7bae833c804..9d59f83c8faa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -655,6 +655,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
}
mutex_unlock(&p->bo_list->bo_list_mutex);
}
+   mutex_unlock(&p->bo_list->bo_list_mutex);
return r;
  }
  

Looks doubtful that this is a correct backport — there's an identical 
mutex_unlock call just above.



Oh, yes good point. This patch doesn't needs to be backported at all 
because it just fixes a problem introduced in the same cycle:


commit 4953b6b22ab9d7f64706631a027b1ed1130ce4c8
Author: Christian König 
Date:   Tue Sep 13 09:52:13 2022 +0200

    drm/amdgpu: cleanup error handling in amdgpu_cs_parser_bos

    Return early on success and so remove all those "if (r)" in the error
    path.

    Signed-off-by: Christian König 
    Reviewed-by: Alex Deucher 
    Signed-off-by: Alex Deucher 

Regards,
Christian.

Re: [PATCH 590/606] backlight: lm3639: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:24PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 591/606] backlight: lp855x: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:25PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> .probe_new() doesn't get the i2c_device_id * parameter, so determine
> that explicitly in the probe function.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 592/606] backlight: lv5207lp: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:26PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 593/606] backlight: tosa: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:27PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH] drm/vc4: Fix NULL pointer access in vc4_platform_drm_probe()

[Dave Stevenson]

Hi Lino

On Sun, 20 Nov 2022 at 15:26, Lino Sanfilippo  wrote:
>
> From: Lino Sanfilippo 
>
> In vc4_platform_drm_probe() function vc4_match_add_drivers() is called to
> find component matches for the component drivers. If no such match is found
> the passed variable "match" is still NULL after the function returns.

This would imply a very strange device tree that has bothered to add
the drm device but none of the devices that are required to run the
DRM pipeline, but avoiding a NULL deref is certainly preferable.

> Do not pass "match" to component_master_add_with_match() in this case since
> this results in a NULL pointer access as soon as match->num is used to
> allocate a component_match array. Instead return with -ENODEV from the
> drivers probe function.
>
> Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lino Sanfilippo 

Acked-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_drv.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 2027063fdc30..2e53d7f8ad44 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -437,6 +437,9 @@ static int vc4_platform_drm_probe(struct platform_device 
> *pdev)
> vc4_match_add_drivers(dev, &match,
>   component_drivers, 
> ARRAY_SIZE(component_drivers));
>
> +   if (!match)
> +   return -ENODEV;
> +
> return component_master_add_with_match(dev, &vc4_drm_ops, match);
>  }
>
>
> base-commit: 30a0b95b1335e12efef89dd78518ed3e4a71a763
> --
> 2.36.1
>

[PATCH] drm/i915/selftests: Fix error return code in live_parallel_switch()

[Ziyang Xuan]

In live_parallel_switch(), excute intel_context_create() failed,
the error code should be set before return from error handling path.

Fixes: 50d16d44cce4 ("drm/i915/selftests: Exercise context switching in 
parallel")
Signed-off-by: Ziyang Xuan 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index c6ad67b90e8a..960ad65e5300 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -335,8 +335,10 @@ static int live_parallel_switch(void *arg)
continue;
 
ce = intel_context_create(data[m].ce[0]->engine);
-   if (IS_ERR(ce))
+   if (IS_ERR(ce)) {
+   err = PTR_ERR(ce);
goto out;
+   }
 
err = intel_context_pin(ce);
if (err) {
-- 
2.25.1

git send-email friendly smtp provider anyone?

[Noralf Trønnes]

Hi

A couple of years ago my email provider blocked me from using git
send-email with their smtp server. So I switched to the one my ISP
provides. Now my ISP have outsourced their email service so the first 3
emails gets through and the rest looks like it ends up in a tar pit or
something, 18 hours later and 5 of 7 emails have gotten through. I have
asked them about this, but I fear the answer will be this is not
supported since they now don't have the service in-house anymore. I'm
waiting for a reply.

Today I tried sendinblue.com since they have a free plan, but they
insert  in the emails so that didn't work out. They also have some
kind of queue, after 1 hour 6 of 7 emails have gotten through.

Does anyone have an smtp provider to recommend that works with git
send-email and that sends out all the emails at once?

I have a patchset that I want to send out.

Noralf.

Re: [PATCH 3/5] kobject: kset_uevent_ops: make filter() callback take a const *

[Rafael J. Wysocki]

On Mon, Nov 21, 2022 at 10:47 AM Greg Kroah-Hartman
 wrote:
>
> The filter() callback in struct kset_uevent_ops does not modify the
> kobject passed into it, so make the pointer const to enforce this
> restriction.  When doing so, fix up all existing filter() callbacks to
> have the correct signature to preserve the build.
>
> Cc: "Rafael J. Wysocki" 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Greg Kroah-Hartman 

Acked-by: Rafael J. Wysocki 

> ---
>  drivers/base/bus.c| 2 +-
>  drivers/base/core.c   | 4 ++--
>  drivers/dma-buf/dma-buf-sysfs-stats.c | 2 +-
>  include/linux/kobject.h   | 2 +-
>  kernel/params.c   | 2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 7ca47e5b3c1f..4ec6dbab73be 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -163,7 +163,7 @@ static struct kobj_type bus_ktype = {
> .release= bus_release,
>  };
>
> -static int bus_uevent_filter(struct kobject *kobj)
> +static int bus_uevent_filter(const struct kobject *kobj)
>  {
> const struct kobj_type *ktype = get_ktype(kobj);
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index a79b99ecf4d8..005a2b092f3e 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2362,12 +2362,12 @@ static struct kobj_type device_ktype = {
>  };
>
>
> -static int dev_uevent_filter(struct kobject *kobj)
> +static int dev_uevent_filter(const struct kobject *kobj)
>  {
> const struct kobj_type *ktype = get_ktype(kobj);
>
> if (ktype == &device_ktype) {
> -   struct device *dev = kobj_to_dev(kobj);
> +   const struct device *dev = kobj_to_dev(kobj);
> if (dev->bus)
> return 1;
> if (dev->class)
> diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c 
> b/drivers/dma-buf/dma-buf-sysfs-stats.c
> index 2bba0babcb62..f69d68122b9b 100644
> --- a/drivers/dma-buf/dma-buf-sysfs-stats.c
> +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
> @@ -132,7 +132,7 @@ void dma_buf_stats_teardown(struct dma_buf *dmabuf)
>
>
>  /* Statistics files do not need to send uevents. */
> -static int dmabuf_sysfs_uevent_filter(struct kobject *kobj)
> +static int dmabuf_sysfs_uevent_filter(const struct kobject *kobj)
>  {
> return 0;
>  }
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index 5a2d58e10bf5..640f59d4b3de 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -135,7 +135,7 @@ struct kobj_uevent_env {
>  };
>
>  struct kset_uevent_ops {
> -   int (* const filter)(struct kobject *kobj);
> +   int (* const filter)(const struct kobject *kobj);
> const char *(* const name)(struct kobject *kobj);
> int (* const uevent)(struct kobject *kobj, struct kobj_uevent_env 
> *env);
>  };
> diff --git a/kernel/params.c b/kernel/params.c
> index 5b92310425c5..d2237209ceda 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -926,7 +926,7 @@ static const struct sysfs_ops module_sysfs_ops = {
> .store = module_attr_store,
>  };
>
> -static int uevent_filter(struct kobject *kobj)
> +static int uevent_filter(const struct kobject *kobj)
>  {
> const struct kobj_type *ktype = get_ktype(kobj);
>
> --
> 2.38.1
>

Re: [PATCH] i2c: qcom-geni: fix error return code in geni_i2c_gpi_xfer

[Tommaso Merciai]

Hi Wang,

On Mon, Nov 21, 2022 at 06:17:52PM +0800, Wang Yufen wrote:
> Fix to return a negative error code from the gi2c->err instead of
> 0.
> 
> Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
> Signed-off-by: Wang Yufen 
> ---
>  drivers/i2c/busses/i2c-qcom-geni.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index 84a7751..8fce98b 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -626,7 +626,6 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, 
> struct i2c_msg msgs[], i
>   dev_err(gi2c->se.dev, "I2C timeout gpi flags:%d 
> addr:0x%x\n",
>   gi2c->cur->flags, gi2c->cur->addr);
>   gi2c->err = -ETIMEDOUT;
> - goto err;


Looks good to me.
Reviewed-by: Tommaso Merciai 

Regards,
Tommaso

>   }
>  
>   if (gi2c->err) {
> -- 
> 1.8.3.1
> 

-- 
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__

Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Andrzej Hajda]

On 21.11.2022 11:59, Janusz Krzysztofik wrote:

On Monday, 21 November 2022 11:51:15 CET Janusz Krzysztofik wrote:

Hi Andrzej,

Thanks for your comment.

On Monday, 21 November 2022 11:17:42 CET Andrzej Hajda wrote:


On 21.11.2022 09:30, Janusz Krzysztofik wrote:

Hi Nimroy,

Thanks for looking at this.

On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:

On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:

Users of intel_gt_retire_requests_timeout() expect 0 return value on
success.  However, we have no protection from passing back 0 potentially
returned by a call to dma_fence_wait_timeout() when it succedes right
after its timeout has expired.

Replace 0 with -ETIME before potentially using the timeout value as return
code, so -ETIME is returned if there are still some requests not retired
after timeout, 0 otherwise.

v2: Move the added lines down so flush_submission() is not affected.

Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with

retire_request")

Signed-off-by: Janusz Krzysztofik 
Cc: sta...@vger.kernel.org # v5.5+
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/

drm/i915/gt/intel_gt_requests.c

index edb881d756309..3ac4603eeb4ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -199,6 +199,9 @@ out_active: spin_lock(&timelines->lock);
if (remaining_timeout)
*remaining_timeout = timeout;

+	if (!timeout)

+   timeout = -ETIME;

This will return error, -ETIME when 0 timeout is passed,
intel_gt_retire_requests().

Yes, but only when active_count is not 0 after we loop through
timelines->active_list calling retire_requests() on each and counting up
failures in active_count.


Moving this line just after the call to dma_fence_wait_timeout should
solve the controversy.


But that would break our need to pass 0, not -ETIME, to flush_submission() in
case the initial value of timeout was 0, as pointed out by Chris during our
discussion on v2.

Maybe an inline comment above the added lines that explains why we are doing
this could help?


How about not adding those two lines but modifying the return line instead?

-   return active_count ? timeout : 0;
+   return active_count ? timeout ?: -ETIME : 0;


Personally I would translate ret value from dma_fence* API ASAP, and 
call flush_submission conditionally - to limit coexistence of both APIs.

But this looks correct to me, as well.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej



Would that be self explanatory?

Thanks,
Janusz



Thanks,
Janusz



Regards
Andrzej




We don't want that.

When 0 timeout is passed to intel_gt_retire_requests(), do we really want it
to return 0 unconditionally, or are we rather interested if those calls to
retire_requests() succeeded?


I think you can use a separate variable to store
return val from the dma_fence_wait_timeout()


Regards,

Nirmoy


+
return active_count ? timeout : 0;

If active count is 0, we return 0 regardless of timeout value, and that's OK.
However, if active_count is not 0, we shouldn't return 0, I believe, we should
return either remaining time if some left, or error (-ETIME) if not.  If you
think I'm wrong, please explain why.

Thanks,
Janusz


}

Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Noralf Trønnes]

Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
> drivers vmap/vunmap GEM buffer memory during the atomic commit.
> Shadow-plane helpers automate this process.
> 
> Patches 1 to 4 prepare the MIPI code for the change and simplify
> the restof the patchset.
> 
> Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
> shadow-plane helpers. Most of the affected drivers call MIPI-DBI
> helpers and get the update automatically. Only ili9225 and st7586
> require changes to their source code.
> 
> Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
> needed, but streamlines the driver code and make sense overall.
> 
> Testing is welcome, as I don't have any hardware to test these
> changes myself.
> 

I can do a test this weekend.

Btw I've converted drm/gud to the shadow plane helper, I just need to
solve an smtp problem[1] so I can send out the patchset.

[1]
https://lore.kernel.org/dri-devel/1bc45775-0667-01f8-36e1-9f65d3081...@tronnes.org/T/#u

Noralf.

Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Thomas Zimmermann]

Hi

Am 21.11.22 um 13:27 schrieb Noralf Trønnes:



Den 21.11.2022 11.45, skrev Thomas Zimmermann:

Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
drivers vmap/vunmap GEM buffer memory during the atomic commit.
Shadow-plane helpers automate this process.

Patches 1 to 4 prepare the MIPI code for the change and simplify
the restof the patchset.

Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
shadow-plane helpers. Most of the affected drivers call MIPI-DBI
helpers and get the update automatically. Only ili9225 and st7586
require changes to their source code.

Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
needed, but streamlines the driver code and make sense overall.

Testing is welcome, as I don't have any hardware to test these
changes myself.



I can do a test this weekend.


Thanks a lot.



Btw I've converted drm/gud to the shadow plane helper, I just need to
solve an smtp problem[1] so I can send out the patchset.


How so?  When I looked at it, the vmap/vunmap happened on a separate 
worker than the commit IIRC.


Best regards
Thomas



[1]
https://lore.kernel.org/dri-devel/1bc45775-0667-01f8-36e1-9f65d3081...@tronnes.org/T/#u

Noralf.


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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v3] drm/i915/mtl: Media GT and Render GT share common GGTT

[Iddamsetty, Aravind]

On 19-11-2022 04:22, Matt Roper wrote:
> On Tue, Nov 15, 2022 at 08:34:54PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared between media and render GT. As a
>> result any updates in GGTT shall invalidate TLB of GTs sharing it and
>> similarly any operation on GGTT requiring an action on a GT will have to
>> involve all GTs sharing it. setup_private_pat was being done on a per
>> GGTT based as that doesn't touch any GGTT structures moved it to per GT
>> based.
>>
>> BSPEC: 63834
>>
>> v2:
>> 1. Add details to commit msg
>> 2. includes fix for failure to add item to ggtt->gt_list, as suggested
>> by Lucas
>> 3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
>> it.
>> 4. setup_private_pat moved out of intel_gt_tiles_init
>>
>> v3:
>> 1. Move out for_each_gt from i915_driver.c (Jani Nikula)
>>
>> Cc: Matt Roper 
>> Signed-off-by: Aravind Iddamsetty 
>> ---
>>  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 54 +--
>>  drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
>>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
>>  drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 ++
>>  drivers/gpu/drm/i915/i915_driver.c| 12 ++---
>>  drivers/gpu/drm/i915/i915_gem.c   |  2 +
>>  drivers/gpu/drm/i915/i915_gem_evict.c | 51 +++--
>>  drivers/gpu/drm/i915/i915_vma.c   |  5 ++-
>>  drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +
>>  9 files changed, 111 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
>> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> index 8145851ad23d..7644738b9cdb 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> @@ -8,6 +8,7 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space 
>> *vm)
>>  
>>  void i915_ggtt_suspend(struct i915_ggtt *ggtt)
>>  {
>> +struct intel_gt *gt;
>> +
>>  i915_ggtt_suspend_vm(&ggtt->vm);
>>  ggtt->invalidate(ggtt);
>>  
>> -intel_gt_check_and_clear_faults(ggtt->vm.gt);
>> +list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
>> +intel_gt_check_and_clear_faults(gt);
>>  }
>>  
>>  void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
>> @@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt 
>> *ggtt)
>>  
>>  static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
>>  {
>> -struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>>  struct drm_i915_private *i915 = ggtt->vm.i915;
>>  
>>  gen8_ggtt_invalidate(ggtt);
>>  
>> -if (GRAPHICS_VER(i915) >= 12)
>> -intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
>> -  GEN12_GUC_TLB_INV_CR_INVALIDATE);
>> -else
>> -intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
>> +if (GRAPHICS_VER(i915) >= 12) {
>> +struct intel_gt *gt;
>> +
>> +list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
>> +intel_uncore_write_fw(gt->uncore,
>> +  GEN12_GUC_TLB_INV_CR,
>> +  GEN12_GUC_TLB_INV_CR_INVALIDATE);
>> +} else {
>> +intel_uncore_write_fw(ggtt->vm.gt->uncore,
>> +  GEN8_GTCR, GEN8_GTCR_INVALIDATE);
>> +}
>>  }
>>  
>>  u64 gen8_ggtt_pte_encode(dma_addr_t addr,
>> @@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>>  
>>  ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
>>  
>> -setup_private_pat(ggtt->vm.gt);
>> -
>>  return ggtt_probe_common(ggtt, size);
>>  }
>>  
>> @@ -1196,7 +1203,14 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, 
>> struct intel_gt *gt)
>>   */
>>  int i915_ggtt_probe_hw(struct drm_i915_private *i915)
>>  {
>> -int ret;
>> +struct intel_gt *gt;
>> +int ret, i;
>> +
>> +for_each_gt(gt, i915, i) {
>> +ret = intel_gt_assign_ggtt(gt);
>> +if (ret)
>> +return ret;
>> +}
>>  
>>  ret = ggtt_probe_hw(to_gt(i915)->ggtt, to_gt(i915));
>>  if (ret)
>> @@ -1208,6 +1222,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
>>  return 0;
>>  }
>>  
>> +struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
>> +{
>> +struct i915_ggtt *ggtt;
>> +
>> +ggtt = drmm_kzalloc(&i915->drm, sizeof(*ggtt), GFP_KERNEL);
>> +if (!ggtt)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +INIT_LIST_HEAD(&ggtt->gt_list);
>> +
>> +return ggtt;
>> +}
>> +
>>  int i915_ggtt_enable_hw(struct drm_i915_private *i915)
>>  {
>>  if (GRAPHICS_VER(i915) < 6)
>> @@ -1296,9 +1323,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space 
>> *vm)
>>  
>>  void i915_ggtt_resume(st

[PATCH] drm/amdgpu: fix unused-function error

[Ren Zhijie]

If CONFIG_DRM_AMDGPU=y and CONFIG_DRM_AMD_DC is not set,
gcc complained about unused-function :

drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1705:13: error: 
‘amdgpu_discovery_set_sriov_display’ defined but not used 
[-Werror=unused-function]
 static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
 ^~
cc1: all warnings being treated as errors

To fix this error, use CONFIG_DRM_AMD_DC to wrap
the definition of amdgpu_discovery_set_sriov_display().

Fixes: 25263da37693 ("drm/amdgpu: rework SR-IOV virtual display handling")
Signed-off-by: Ren Zhijie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 6b48178455bc..2509341df92d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -1702,11 +1702,13 @@ static int amdgpu_discovery_set_smu_ip_blocks(struct 
amdgpu_device *adev)
return 0;
 }
 
+#if defined(CONFIG_DRM_AMD_DC)
 static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
 {
amdgpu_device_set_sriov_virtual_display(adev);
amdgpu_device_ip_block_add(adev, &amdgpu_vkms_ip_block);
 }
+#endif
 
 static int amdgpu_discovery_set_display_ip_blocks(struct amdgpu_device *adev)
 {
-- 
2.17.1

Re: git send-email friendly smtp provider anyone?

[Simon Ser]

I think you can apply for a linux.dev mailbox [1].

[1]: https://korg.docs.kernel.org/linuxdev.html

[PATCH] gpu: vgpu: delete a semicolon

[Li kunyu]

Remove extra semicolons at the end of statements to make them look
cleaner.

Signed-off-by: Li kunyu 
---
 drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 56c71474008a..5ccb04e26e6d 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -325,7 +325,7 @@ int intel_gvt_create_vgpu(struct intel_vgpu *vgpu,
ret = idr_alloc(&gvt->vgpu_idr, vgpu, IDLE_VGPU_IDR + 1, GVT_MAX_VGPU,
GFP_KERNEL);
if (ret < 0)
-   goto out_unlock;;
+   goto out_unlock;
 
vgpu->id = ret;
vgpu->sched_ctl.weight = conf->weight;
-- 
2.18.2

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

[Carlo Caione]

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

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

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

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

 drivers/gpu/drm/tiny/ili9486.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)
---
base-commit: 147307c69ba4441ee90c1f8ce8edf5df4ea60f67
change-id: 20221116-s905x_spi_ili9486-aed54ff3cb21

Best regards,
-- 
Carlo Caione

[PATCH v2 1/2] drm/tiny: rpi-lcd-35: Enable driver module autoloading

[Carlo Caione]

SPI devices use the spi_device_id for module autoloading even on
systems using device tree.

Add the spi_device_id entry to enable autoloading for the 3.5inch RPi
Display (rpi-lcd-35).

Signed-off-by: Carlo Caione 
---
 drivers/gpu/drm/tiny/ili9486.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 1bb847466b10..bd37dfe8dd05 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -183,6 +183,7 @@ MODULE_DEVICE_TABLE(of, ili9486_of_match);
 
 static const struct spi_device_id ili9486_id[] = {
{ "ili9486", 0 },
+   { "rpi-lcd-35", 0 },
{ }
 };
 MODULE_DEVICE_TABLE(spi, ili9486_id);

-- 
b4 0.10.1

[PATCH v2 2/2] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers

[Carlo Caione]

The pixel data for the ILI9486 is always 16-bits wide and it must be
sent over the SPI bus. When the controller is only able to deal with
8-bit transfers, this 16-bits data needs to be swapped before the
sending to account for the big endian bus, this is on the contrary not
needed when the SPI controller already supports 16-bits transfers.

The decision about swapping the pixel data or not is taken in the MIPI
DBI code by probing the controller capabilities: if the controller only
suppors 8-bit transfers the data is swapped, otherwise it is not.

This swapping/non-swapping is relying on the assumption that when the
controller does support 16-bit transactions then the data is sent
unswapped in 16-bits-per-word over SPI.

The problem with the ILI9486 driver is that it is forcing 8-bit
transactions also for controllers supporting 16-bits, violating the
assumption and corrupting the pixel data.

Align the driver to what is done in the MIPI DBI code by adjusting the
tranfer size to the maximum allowed by the SPI controller.

Signed-off-by: Carlo Caione 
---
 drivers/gpu/drm/tiny/ili9486.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index bd37dfe8dd05..4d80a413338f 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -43,6 +43,7 @@ static int waveshare_command(struct mipi_dbi *mipi, u8 *cmd, 
u8 *par,
 size_t num)
 {
struct spi_device *spi = mipi->spi;
+   unsigned int bpw = 8;
void *data = par;
u32 speed_hz;
int i, ret;
@@ -56,8 +57,6 @@ static int waveshare_command(struct mipi_dbi *mipi, u8 *cmd, 
u8 *par,
 * The displays are Raspberry Pi HATs and connected to the 8-bit only
 * SPI controller, so 16-bit command and parameters need byte swapping
 * before being transferred as 8-bit on the big endian SPI bus.
-* Pixel data bytes have already been swapped before this function is
-* called.
 */
buf[0] = cpu_to_be16(*cmd);
gpiod_set_value_cansleep(mipi->dc, 0);
@@ -71,12 +70,18 @@ static int waveshare_command(struct mipi_dbi *mipi, u8 
*cmd, u8 *par,
for (i = 0; i < num; i++)
buf[i] = cpu_to_be16(par[i]);
num *= 2;
-   speed_hz = mipi_dbi_spi_cmd_max_speed(spi, num);
data = buf;
}
 
+   /*
+* Check whether pixel data bytes needs to be swapped or not
+*/
+   if (*cmd == MIPI_DCS_WRITE_MEMORY_START && !mipi->swap_bytes)
+   bpw = 16;
+
gpiod_set_value_cansleep(mipi->dc, 1);
-   ret = mipi_dbi_spi_transfer(spi, speed_hz, 8, data, num);
+   speed_hz = mipi_dbi_spi_cmd_max_speed(spi, num);
+   ret = mipi_dbi_spi_transfer(spi, speed_hz, bpw, data, num);
  free:
kfree(buf);
 

-- 
b4 0.10.1

[PATCH] i2c: qcom-geni: fix error return code in geni_i2c_gpi_xfer

[Wang Yufen]

Fix to return a negative error code from the gi2c->err instead of
0.

Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
Signed-off-by: Wang Yufen 
---
 drivers/i2c/busses/i2c-qcom-geni.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
b/drivers/i2c/busses/i2c-qcom-geni.c
index 84a7751..8fce98b 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -626,7 +626,6 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, 
struct i2c_msg msgs[], i
dev_err(gi2c->se.dev, "I2C timeout gpi flags:%d 
addr:0x%x\n",
gi2c->cur->flags, gi2c->cur->addr);
gi2c->err = -ETIMEDOUT;
-   goto err;
}
 
if (gi2c->err) {
-- 
1.8.3.1

[PATCH] drm/logicvc: Drop obsolete dependency on COMPILE_TEST

[Jean Delvare]

Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.

It is actually better to always build such drivers with OF enabled,
so that the test builds are closer to how each driver will actually be
built on its intended target. Building them without OF may not test
much as the compiler will optimize out potentially large parts of the
code. In the worst case, this could even pop false positive warnings.
Dropping COMPILE_TEST here improves the quality of our testing and
avoids wasting time on non-existent issues.

Signed-off-by: Jean Delvare 
Cc: Paul Kocialkowski 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/logicvc/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-6.0.orig/drivers/gpu/drm/logicvc/Kconfig
+++ linux-6.0/drivers/gpu/drm/logicvc/Kconfig
@@ -1,7 +1,7 @@
 config DRM_LOGICVC
tristate "LogiCVC DRM"
depends on DRM
-   depends on OF || COMPILE_TEST
+   depends on OF
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER


-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH v10 00/19] drm: Analog TV Improvements

[Daniel Vetter]

On Thu, Nov 17, 2022 at 10:28:43AM +0100, Maxime Ripard wrote:
> Hi,
> 
> Here's a series aiming at improving the command line named modes support,
> and more importantly how we deal with all the analog TV variants.
> 
> The named modes support were initially introduced to allow to specify the
> analog TV mode to be used.
> 
> However, this was causing multiple issues:
> 
>   * The mode name parsed on the command line was passed directly to the
> driver, which had to figure out which mode it was suppose to match;
> 
>   * Figuring that out wasn't really easy, since the video= argument or what
> the userspace might not even have a name in the first place, but
> instead could have passed a mode with the same timings;
> 
>   * The fallback to matching on the timings was mostly working as long as
> we were supporting one 525 lines (most likely NSTC) and one 625 lines
> (PAL), but couldn't differentiate between two modes with the same
> timings (NTSC vs PAL-M vs NSTC-J for example);
> 
>   * There was also some overlap with the tv mode property registered by
> drm_mode_create_tv_properties(), but named modes weren't interacting
> with that property at all.
> 
>   * Even though that property was generic, its possible values were
> specific to each drivers, which made some generic support difficult.
> 
> Thus, I chose to tackle in multiple steps:
> 
>   * A new TV mode property was introduced, with generic values, each driver
> reporting through a bitmask what standard it supports to the userspace;
> 
>   * This option was added to the command line parsing code to be able to
> specify it on the kernel command line, and new atomic_check and reset
> helpers were created to integrate properly into atomic KMS;
> 
>   * The named mode parsing code is now creating a proper display mode for
> the given named mode, and the TV standard will thus be part of the
> connector state;
> 
>   * Two drivers were converted and tested for now (vc4 and sun4i), with
> some backward compatibility code to translate the old TV mode to the
> new TV mode;
> 
> Unit tests were created along the way.
> 
> One can switch from NTSC to PAL now using (on vc4)
> 
> modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
> modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL
> 
> Let me know what you think,
> Maxime

Maxime asked me to drop an Ack-in-principle on this, and I'm not sure I
have any useful input here with my utter lack of understanding for TV
things (I never even had one in my entire life, that's how much I don't
care). But it seems to check all the design boxes around solving annoying
uapi/kms-config issues properly, so

Acked-in-principle-or-something-like-that-by: Daniel Vetter 


Cheers, Daniel

> 
> To: David Airlie 
> To: Daniel Vetter 
> To: Maarten Lankhorst 
> To: Maxime Ripard 
> To: Thomas Zimmermann 
> To: Emma Anholt 
> To: Jani Nikula 
> To: Joonas Lahtinen 
> To: Rodrigo Vivi 
> To: Tvrtko Ursulin 
> To: Ben Skeggs 
> To: Karol Herbst 
> To: Lyude Paul 
> To: Chen-Yu Tsai 
> To: Jernej Skrabec 
> To: Samuel Holland 
> Cc: Geert Uytterhoeven 
> Cc: Mateusz Kwiatkowski 
> Cc: "Noralf Trønnes" 
> Cc: Dave Stevenson 
> Cc: Dom Cobley 
> Cc: Phil Elwell 
> Cc: 
> Cc: linux-ker...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-su...@lists.linux.dev
> Cc: Hans de Goede 
> Signed-off-by: Maxime Ripard 
> 
> ---
> Changes in v10:
> - Rebase on top of drm-misc-next-2022-11-17
> - Fix checkpatch issues
> - Add missing MODULE_* macros
> - Link to v9: 
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v9-0-24b168e5b...@cerno.tech
> 
> Changes in v9:
> - Rename some tests, switch to kunit_test_suite and parameterized tests where
>   relevant
> - Document the valid named modes
> - Link to v8: 
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v8-0-09ce14669...@cerno.tech
> 
> Changes in v8:
> - Changed slightly the helper API to pass in the features
> - Removed unused tv_mode_support function
> - Removed mode name match in _pick_cmdline_mode
> - Added unit tests to the get_modes helper
> - Collected Noralf and Mateusz tags
> - Rebased on drm-misc-next-2022-11-10
> - Link to v7: 
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v7-0-7072a478c...@cerno.tech
> 
> Changes in v7:
> - Switch to another implementation of get_modes from Noralf
> - Made more checks in VEC's atomic_check
> - Fixed typo in a commit log
> - Checked for tv_mode_specified in drm_mode_parse_command_line_for_connector
> - Rebased on drm-misc-next-2022-11-03
> - Link to v6: 
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v6-0-e77927341...@cerno.tech
> 
> Changes in v6:
> - Add and convert to a new get_modes helper to create the PAL and NTSC modes 
> in
>   the proper order, with the right preferred mode flag, depending on the 
> driver
>   capabilities

[PATCH v3 1/2] drm/i915: Fix negative value passed as remaining time

[Janusz Krzysztofik]

Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
with GuC") extended the API of intel_gt_retire_requests_timeout() with an
extra argument 'remaining_timeout', intended for passing back unconsumed
portion of requested timeout when 0 (success) is returned.  However, when
request retirement happens to succeed despite an error returned by a call
to dma_fence_wait_timeout(), that error code (a negative value) is passed
back instead of remaining time.  If we then pass that negative value
forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG
will be triggered.

If request retirement succeeds but an error code is passed back via
remaininig_timeout, we may have no clue on how much of the initial timeout
might have been left for spending it on waiting for GuC to become idle.
OTOH, since all pending requests have been successfully retired, that
error code has been already ignored by intel_gt_retire_requests_timeout(),
then we shouldn't fail.

Assume no more time has been left on error and pass 0 timeout value to
intel_uc_wait_for_idle() to give it a chance to return success if GuC is
already idle.

v3: Don't fail on any error passed back via remaining_timeout.

v2: Fix the issue on the caller side, not the provider.

Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with 
GuC")
Signed-off-by: Janusz Krzysztofik 
Cc: sta...@vger.kernel.org # v5.15+
---
 drivers/gpu/drm/i915/gt/intel_gt.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b5ad9caa55372..7ef0edb2e37cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -677,8 +677,13 @@ int intel_gt_wait_for_idle(struct intel_gt *gt, long 
timeout)
return -EINTR;
}
 
-   return timeout ? timeout : intel_uc_wait_for_idle(>->uc,
- remaining_timeout);
+   if (timeout)
+   return timeout;
+
+   if (remaining_timeout < 0)
+   remaining_timeout = 0;
+
+   return intel_uc_wait_for_idle(>->uc, remaining_timeout);
 }
 
 int intel_gt_init(struct intel_gt *gt)
-- 
2.25.1

[PATCH v3 0/2] drm/i915: Fix timeout handling when retiring requests

[Janusz Krzysztofik]

Fixes for issues discovered via code review while working on
https://gitlab.freedesktop.org/drm/intel/issues/7349.

v3:
PATCH 1: don't fail on any error passed back via remaining_timeout,
PATCH 2: use conditional expression, more compact but also better
 reflecting intention standing behind the change.

v2:
PATCH 1: fix the issue on the caller side, not the provider,
 reword commit message and description.
PATCH 2: move the added lines down so flush_submission() is not affected,
 reword commit message and description.
PATCH 3: drop -- controversial, not needed.

Janusz Krzysztofik (2):
  drm/i915: Fix negative value passed as remaining time
  drm/i915: Never return 0 if not all requests retired

 drivers/gpu/drm/i915/gt/intel_gt.c  | 9 +++--
 drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.25.1

[PATCH v3 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

Users of intel_gt_retire_requests_timeout() expect 0 return value on
success.  However, we have no protection from passing back 0 potentially
returned by a call to dma_fence_wait_timeout() when it succedes right
after its timeout has expired.

Replace 0 with -ETIME before potentially using the timeout value as return
code, so -ETIME is returned if there are still some requests not retired
after timeout, 0 otherwise.

v3: Use conditional expression, more compact but also better reflecting
intention standing behind the change.

v2: Move the added lines down so flush_submission() is not affected.

Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request")
Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Andrzej Hajda 
Cc: sta...@vger.kernel.org # v5.5+
---
 drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c 
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index edb881d756309..1dfd01668c79c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -199,7 +199,7 @@ out_active: spin_lock(&timelines->lock);
if (remaining_timeout)
*remaining_timeout = timeout;
 
-   return active_count ? timeout : 0;
+   return active_count ? timeout ?: -ETIME : 0;
 }
 
 static void retire_work_handler(struct work_struct *work)
-- 
2.25.1

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Thomas Zimmermann]

Acked-by: Thomas Zimmermann 

Am 19.11.22 um 21:44 schrieb Oded Gabbay:

This is the fourth (and hopefully last) version of the patch-set to add the
new subsystem for compute accelerators. I removed the RFC headline as
I believe it is now ready for merging.

Compare to v3, this patch-set contains one additional patch that adds
documentation regarding the accel subsystem. I hope it's good enough for
this stage. In addition, there were few very minor fixes according to
comments received on v3.

The patches are in the following repo:
https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4

As in v3, The HEAD of that branch is a commit adding a dummy driver that
registers an accel device using the new framework. This can be served
as a simple reference.

v1 cover letter:
https://lkml.org/lkml/2022/10/22/544

v2 cover letter:
https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/

v3 cover letter:
https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/

Thanks,
Oded.

Oded Gabbay (4):
   drivers/accel: define kconfig and register a new major
   accel: add dedicated minor for accelerator devices
   drm: initialize accel framework
   doc: add documentation for accel subsystem

  Documentation/accel/index.rst |  17 ++
  Documentation/accel/introduction.rst  | 109 +
  Documentation/admin-guide/devices.txt |   5 +
  Documentation/subsystem-apis.rst  |   1 +
  MAINTAINERS   |   9 +
  drivers/Kconfig   |   2 +
  drivers/accel/Kconfig |  24 ++
  drivers/accel/drm_accel.c | 323 ++
  drivers/gpu/drm/Makefile  |   1 +
  drivers/gpu/drm/drm_drv.c | 102 +---
  drivers/gpu/drm/drm_file.c|   2 +-
  drivers/gpu/drm/drm_sysfs.c   |  24 +-
  include/drm/drm_accel.h   |  97 
  include/drm/drm_device.h  |   3 +
  include/drm/drm_drv.h |   8 +
  include/drm/drm_file.h|  21 +-
  16 files changed, 711 insertions(+), 37 deletions(-)
  create mode 100644 Documentation/accel/index.rst
  create mode 100644 Documentation/accel/introduction.rst
  create mode 100644 drivers/accel/Kconfig
  create mode 100644 drivers/accel/drm_accel.c
  create mode 100644 include/drm/drm_accel.h

--
2.25.1



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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Oded Gabbay]

On Mon, Nov 21, 2022 at 8:26 AM Dave Airlie  wrote:
>
> On Sun, 20 Nov 2022 at 06:44, Oded Gabbay  wrote:
> >
> > This is the fourth (and hopefully last) version of the patch-set to add the
> > new subsystem for compute accelerators. I removed the RFC headline as
> > I believe it is now ready for merging.
> >
> > Compare to v3, this patch-set contains one additional patch that adds
> > documentation regarding the accel subsystem. I hope it's good enough for
> > this stage. In addition, there were few very minor fixes according to
> > comments received on v3.
> >
> > The patches are in the following repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
> >
> > As in v3, The HEAD of that branch is a commit adding a dummy driver that
> > registers an accel device using the new framework. This can be served
> > as a simple reference.
> >
>
> FIx the nits Jeffery raised and the one I brought up and I think we
> should be good for this to be in a PR.
>
> Reviewed-by: Dave Airlie 
Sure, np.
Oded

Re: [PATCH v4 2/4] accel: add dedicated minor for accelerator devices

[Oded Gabbay]

On Sun, Nov 20, 2022 at 11:47 PM Jeffrey Hugo  wrote:
>
> On 11/19/2022 1:44 PM, Oded Gabbay wrote:
> > diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
> > index fac6ad6ac28e..703d40c4ff45 100644
> > --- a/drivers/accel/drm_accel.c
> > +++ b/drivers/accel/drm_accel.c
> > @@ -8,14 +8,25 @@
> >
> >   #include 
> >   #include 
> > +#include 
>
> Including xarray, but using idr
> This should be linux/idr.h
>
> This seems so minor, I don't think I advise spinning a v5 for it.  If a
> v5 is warranted elsewhere, obviously fix this.  If not, hopefully this
> can be fixed up by whoever applies it, or someone submits a follow up patch.
>
> Hopefully this is the only nit.  I would like to see this merged.
>
> -Jeff
Thanks,
I'll update it before sending the PR.
Oded

Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Noralf Trønnes]

Den 21.11.2022 13.41, skrev Thomas Zimmermann:
> Hi
> 
> Am 21.11.22 um 13:27 schrieb Noralf Trønnes:
>>
>>
>> Den 21.11.2022 11.45, skrev Thomas Zimmermann:
>>> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
>>> drivers vmap/vunmap GEM buffer memory during the atomic commit.
>>> Shadow-plane helpers automate this process.
>>>
>>> Patches 1 to 4 prepare the MIPI code for the change and simplify
>>> the restof the patchset.
>>>
>>> Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
>>> shadow-plane helpers. Most of the affected drivers call MIPI-DBI
>>> helpers and get the update automatically. Only ili9225 and st7586
>>> require changes to their source code.
>>>
>>> Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
>>> needed, but streamlines the driver code and make sense overall.
>>>
>>> Testing is welcome, as I don't have any hardware to test these
>>> changes myself.
>>>
>>
>> I can do a test this weekend.
> 
> Thanks a lot.
> 
>>
>> Btw I've converted drm/gud to the shadow plane helper, I just need to
>> solve an smtp problem[1] so I can send out the patchset.
> 
> How so?  When I looked at it, the vmap/vunmap happened on a separate
> worker than the commit IIRC.
> 

Yes you're right, originally the driver only did flushing asynchronously
in a worker which meant it could access the framebuffer at the same time
as userspace. Later when GNOME got support for one rendering loop per
display, I added a module parameter to enable synchronous flushing
during the commit, it also uses the worker for this but waits for it to
complete.

What I've done in the patchset is to inline the sync flushing and use a
shadow buffer for the async path which still uses the worker, but now it
won't risk reading the framebuffer while userspace writes to it, instead
it reads from the shadow buffer.

Noralf.

> Best regards
> Thomas
> 
>>
>> [1]
>> https://lore.kernel.org/dri-devel/1bc45775-0667-01f8-36e1-9f65d3081...@tronnes.org/T/#u
>>
>> Noralf.
> 

Re: [PATCH v4 4/4] doc: add documentation for accel subsystem

[Oded Gabbay]

On Mon, Nov 21, 2022 at 12:02 AM Jeffrey Hugo  wrote:
>
> On 11/19/2022 1:44 PM, Oded Gabbay wrote:
> > Add an introduction section for the accel subsystem. Most of the
> > relevant data is in the DRM documentation, so the introduction only
> > presents the why of the new subsystem, how are the compute accelerators
> > exposed to user-space and what changes need to be done in a standard
> > DRM driver to register it to the new accel subsystem.
> >
> > Signed-off-by: Oded Gabbay 
> > ---
> >   Documentation/accel/index.rst|  17 +
> >   Documentation/accel/introduction.rst | 109 +++
> >   Documentation/subsystem-apis.rst |   1 +
> >   MAINTAINERS  |   1 +
> >   4 files changed, 128 insertions(+)
> >   create mode 100644 Documentation/accel/index.rst
> >   create mode 100644 Documentation/accel/introduction.rst
> >
> > diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst
> > new file mode 100644
> > index ..2b43c9a7f67b
> > --- /dev/null
> > +++ b/Documentation/accel/index.rst
> > @@ -0,0 +1,17 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +
> > +Compute Accelerators
> > +
> > +
> > +.. toctree::
> > +   :maxdepth: 1
> > +
> > +   introduction
> > +
> > +.. only::  subproject and html
> > +
> > +   Indices
> > +   ===
> > +
> > +   * :ref:`genindex`
> > diff --git a/Documentation/accel/introduction.rst 
> > b/Documentation/accel/introduction.rst
> > new file mode 100644
> > index ..5a3963eae973
> > --- /dev/null
> > +++ b/Documentation/accel/introduction.rst
> > @@ -0,0 +1,109 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +
> > +Introduction
> > +
> > +
> > +The Linux compute accelerators subsystem is designed to expose compute
> > +accelerators in a common way to user-space and provide a common set of
> > +functionality.
> > +
> > +These devices can be either stand-alone ASICs or IP blocks inside an 
> > SoC/GPU.
> > +Although these devices are typically designed to accelerate 
> > Machine-Learning
> > +and/or Deep-Learning computations, the accel layer is not limited to 
> > handling
>
> You use "DL" later on as a short form for Deep-Learning.  It would be
> good to introduce that here.
>
> > +these types of accelerators.
> > +
> > +typically, a compute accelerator will belong to one of the following
>
> Typically
>
> > +categories:
> > +
> > +- Edge AI - doing inference at an edge device. It can be an embedded 
> > ASIC/FPGA,
> > +  or an IP inside a SoC (e.g. laptop web camera). These devices
> > +  are typically configured using registers and can work with or without 
> > DMA.
> > +
> > +- Inference data-center - single/multi user devices in a large server. This
> > +  type of device can be stand-alone or an IP inside a SoC or a GPU. It will
> > +  have on-board DRAM (to hold the DL topology), DMA engines and
> > +  command submission queues (either kernel or user-space queues).
> > +  It might also have an MMU to manage multiple users and might also enable
> > +  virtualization (SR-IOV) to support multiple VMs on the same device. In
> > +  addition, these devices will usually have some tools, such as profiler 
> > and
> > +  debugger.
> > +
> > +- Training data-center - Similar to Inference data-center cards, but 
> > typically
> > +  have more computational power and memory b/w (e.g. HBM) and will likely 
> > have
> > +  a method of scaling-up/out, i.e. connecting to other training cards 
> > inside
> > +  the server or in other servers, respectively.
> > +
> > +All these devices typically have different runtime user-space software 
> > stacks,
> > +that are tailored-made to their h/w. In addition, they will also probably
> > +include a compiler to generate programs to their custom-made computational
> > +engines. Typically, the common layer in user-space will be the DL 
> > frameworks,
> > +such as PyTorch and TensorFlow.
> > +
> > +Sharing code with DRM
> > +=
> > +
> > +Because this type of devices can be an IP inside GPUs or have similar
> > +characteristics as those of GPUs, the accel subsystem will use the
> > +DRM subsystem's code and functionality. i.e. the accel core code will
> > +be part of the DRM subsystem and an accel device will be a new type of DRM
> > +device.
> > +
> > +This will allow us to leverage the extensive DRM code-base and
> > +collaborate with DRM developers that have experience with this type of
> > +devices. In addition, new features that will be added for the accelerator
> > +drivers can be of use to GPU drivers as well.
> > +
> > +Differentiation from GPUs
> > +=
> > +
> > +Because we want to prevent the extensive user-space graphic software stack
> > +from trying to use an accelerator as a GPU, the compute accelerators will 
> > be
> > +differentiated from GPUs by using a new major number and new device char 
> > files.
> > +
> > +Furth

Re: git send-email friendly smtp provider anyone?

[Maxime Ripard]

On Mon, Nov 21, 2022 at 12:48:52PM +0100, Noralf Trønnes wrote:
> A couple of years ago my email provider blocked me from using git
> send-email with their smtp server. So I switched to the one my ISP
> provides. Now my ISP have outsourced their email service so the first 3
> emails gets through and the rest looks like it ends up in a tar pit or
> something, 18 hours later and 5 of 7 emails have gotten through. I have
> asked them about this, but I fear the answer will be this is not
> supported since they now don't have the service in-house anymore. I'm
> waiting for a reply.
> 
> Today I tried sendinblue.com since they have a free plan, but they
> insert  in the emails so that didn't work out. They also have some
> kind of queue, after 1 hour 6 of 7 emails have gotten through.
> 
> Does anyone have an smtp provider to recommend that works with git
> send-email and that sends out all the emails at once?

I'm using fastmail and am very happy about it so far.

Otherwise, you might consider using:
https://b4.docs.kernel.org/en/latest/contributor/send.html#authenticating-with-the-web-submission-endpoint

Maxime


signature.asc
Description: PGP signature

Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Javier Martinez Canillas]

On 11/21/22 13:27, Noralf Trønnes wrote:
> 
> 
> Den 21.11.2022 11.45, skrev Thomas Zimmermann:
>> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
>> drivers vmap/vunmap GEM buffer memory during the atomic commit.
>> Shadow-plane helpers automate this process.
>>
>> Patches 1 to 4 prepare the MIPI code for the change and simplify
>> the restof the patchset.
>>
>> Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
>> shadow-plane helpers. Most of the affected drivers call MIPI-DBI
>> helpers and get the update automatically. Only ili9225 and st7586
>> require changes to their source code.
>>
>> Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
>> needed, but streamlines the driver code and make sense overall.
>>
>> Testing is welcome, as I don't have any hardware to test these
>> changes myself.
>>
> 
> I can do a test this weekend.
>

I've a ST7735 display so I can also give it a test this weekend.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH v4 4/4] doc: add documentation for accel subsystem

[Jeffrey Hugo]

On 11/21/2022 8:18 AM, Oded Gabbay wrote:

On Mon, Nov 21, 2022 at 12:02 AM Jeffrey Hugo  wrote:


On 11/19/2022 1:44 PM, Oded Gabbay wrote:

Add an introduction section for the accel subsystem. Most of the
relevant data is in the DRM documentation, so the introduction only
presents the why of the new subsystem, how are the compute accelerators
exposed to user-space and what changes need to be done in a standard
DRM driver to register it to the new accel subsystem.

Signed-off-by: Oded Gabbay 
---
   Documentation/accel/index.rst|  17 +
   Documentation/accel/introduction.rst | 109 +++
   Documentation/subsystem-apis.rst |   1 +
   MAINTAINERS  |   1 +
   4 files changed, 128 insertions(+)
   create mode 100644 Documentation/accel/index.rst
   create mode 100644 Documentation/accel/introduction.rst

diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst
new file mode 100644
index ..2b43c9a7f67b
--- /dev/null
+++ b/Documentation/accel/index.rst
@@ -0,0 +1,17 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Compute Accelerators
+
+
+.. toctree::
+   :maxdepth: 1
+
+   introduction
+
+.. only::  subproject and html
+
+   Indices
+   ===
+
+   * :ref:`genindex`
diff --git a/Documentation/accel/introduction.rst 
b/Documentation/accel/introduction.rst
new file mode 100644
index ..5a3963eae973
--- /dev/null
+++ b/Documentation/accel/introduction.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Introduction
+
+
+The Linux compute accelerators subsystem is designed to expose compute
+accelerators in a common way to user-space and provide a common set of
+functionality.
+
+These devices can be either stand-alone ASICs or IP blocks inside an SoC/GPU.
+Although these devices are typically designed to accelerate Machine-Learning
+and/or Deep-Learning computations, the accel layer is not limited to handling


You use "DL" later on as a short form for Deep-Learning.  It would be
good to introduce that here.


+these types of accelerators.
+
+typically, a compute accelerator will belong to one of the following


Typically


+categories:
+
+- Edge AI - doing inference at an edge device. It can be an embedded ASIC/FPGA,
+  or an IP inside a SoC (e.g. laptop web camera). These devices
+  are typically configured using registers and can work with or without DMA.
+
+- Inference data-center - single/multi user devices in a large server. This
+  type of device can be stand-alone or an IP inside a SoC or a GPU. It will
+  have on-board DRAM (to hold the DL topology), DMA engines and
+  command submission queues (either kernel or user-space queues).
+  It might also have an MMU to manage multiple users and might also enable
+  virtualization (SR-IOV) to support multiple VMs on the same device. In
+  addition, these devices will usually have some tools, such as profiler and
+  debugger.
+
+- Training data-center - Similar to Inference data-center cards, but typically
+  have more computational power and memory b/w (e.g. HBM) and will likely have
+  a method of scaling-up/out, i.e. connecting to other training cards inside
+  the server or in other servers, respectively.
+
+All these devices typically have different runtime user-space software stacks,
+that are tailored-made to their h/w. In addition, they will also probably
+include a compiler to generate programs to their custom-made computational
+engines. Typically, the common layer in user-space will be the DL frameworks,
+such as PyTorch and TensorFlow.
+
+Sharing code with DRM
+=
+
+Because this type of devices can be an IP inside GPUs or have similar
+characteristics as those of GPUs, the accel subsystem will use the
+DRM subsystem's code and functionality. i.e. the accel core code will
+be part of the DRM subsystem and an accel device will be a new type of DRM
+device.
+
+This will allow us to leverage the extensive DRM code-base and
+collaborate with DRM developers that have experience with this type of
+devices. In addition, new features that will be added for the accelerator
+drivers can be of use to GPU drivers as well.
+
+Differentiation from GPUs
+=
+
+Because we want to prevent the extensive user-space graphic software stack
+from trying to use an accelerator as a GPU, the compute accelerators will be
+differentiated from GPUs by using a new major number and new device char files.
+
+Furthermore, the drivers will be located in a separate place in the kernel
+tree - drivers/accel/.
+
+The accelerator devices will be exposed to the user space with the dedicated
+261 major number and will have the following convention:
+
+- device char files - /dev/accel/accel*
+- sysfs - /sys/class/accel/accel*/
+- debugfs   - /sys/kernel/debug/accel/accel*/
+
+Getting Started
+===
+
+First, read the DRM documentation. Not onl

Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()

[Dawei Li]

On Sat, Nov 05, 2022 at 12:05:36AM +0800, Dawei Li wrote:

Hi Christian,
May I have your opinion on this change?

Thanks,
Dawei

> Racing conflict could be:
> task A task B
> list_for_each_entry
> strcmp(h->name))
>list_for_each_entry
>strcmp(h->name)
> kzallockzalloc
> .. .
> device_create  device_create
> list_add
>list_add
> 
> The root cause is that task B has no idea about the fact someone
> else(A) has inserted heap with same name when it calls list_add,
> so a potential collision occurs.
> 
> Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
> Signed-off-by: Dawei Li 
> ---
> v1: 
> https://lore.kernel.org/all/tycp286mb2323950197f60fc3473123b7ca...@tycp286mb2323.jpnp286.prod.outlook.com/
> v1->v2: Narrow down locking scope, check the existence of heap before
> insertion, as suggested by Andrew Davis.
> v2->v3: Remove double checking.
> v3->v4: Minor coding style and patch formatting adjustment.
> ---
>  drivers/dma-buf/dma-heap.c | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index 8f5848aa144f..59d158873f4c 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct 
> dma_heap_export_info *exp_info)
>   return ERR_PTR(-EINVAL);
>   }
>  
> - /* check the name is unique */
> - mutex_lock(&heap_list_lock);
> - list_for_each_entry(h, &heap_list, list) {
> - if (!strcmp(h->name, exp_info->name)) {
> - mutex_unlock(&heap_list_lock);
> - pr_err("dma_heap: Already registered heap named %s\n",
> -exp_info->name);
> - return ERR_PTR(-EINVAL);
> - }
> - }
> - mutex_unlock(&heap_list_lock);
> -
>   heap = kzalloc(sizeof(*heap), GFP_KERNEL);
>   if (!heap)
>   return ERR_PTR(-ENOMEM);
> @@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct 
> dma_heap_export_info *exp_info)
>   err_ret = ERR_CAST(dev_ret);
>   goto err2;
>   }
> - /* Add heap to the list */
> +
>   mutex_lock(&heap_list_lock);
> + /* check the name is unique */
> + list_for_each_entry(h, &heap_list, list) {
> + if (!strcmp(h->name, exp_info->name)) {
> + mutex_unlock(&heap_list_lock);
> + pr_err("dma_heap: Already registered heap named %s\n",
> +exp_info->name);
> + err_ret = ERR_PTR(-EINVAL);
> + goto err3;
> + }
> + }
> +
> + /* Add heap to the list */
>   list_add(&heap->list, &heap_list);
>   mutex_unlock(&heap_list_lock);
>  
>   return heap;
>  
> +err3:
> + device_destroy(dma_heap_class, heap->heap_devt);
>  err2:
>   cdev_del(&heap->heap_cdev);
>  err1:
> -- 
> 2.25.1
> 

[PATCH resend] drm/armada: Fix off-by-one error in armada_overlay_get_property()

[Geert Uytterhoeven]

As ffs() returns one more than the index of the first bit set (zero
means no bits set), the color key mode value is shifted one position too
much.

Fix this by using FIELD_GET() instead.

Fixes: c96103b6c49ff9a8 ("drm/armada: move colorkey properties into overlay 
plane state")
Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.
---
 drivers/gpu/drm/armada/armada_overlay.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index f21eb8fb76d87285..3b9bd8ecda137f6d 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -4,6 +4,8 @@
  *  Rewritten from the dovefb driver, and Armada510 manuals.
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -445,8 +447,8 @@ static int armada_overlay_get_property(struct drm_plane 
*plane,
 drm_to_overlay_state(state)->colorkey_ug,
 drm_to_overlay_state(state)->colorkey_vb, 0);
} else if (property == priv->colorkey_mode_prop) {
-   *val = (drm_to_overlay_state(state)->colorkey_mode &
-   CFG_CKMODE_MASK) >> ffs(CFG_CKMODE_MASK);
+   *val = FIELD_GET(CFG_CKMODE_MASK,
+drm_to_overlay_state(state)->colorkey_mode);
} else if (property == priv->brightness_prop) {
*val = drm_to_overlay_state(state)->brightness + 256;
} else if (property == priv->contrast_prop) {
-- 
2.25.1

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Alex Deucher]

On Sat, Nov 19, 2022 at 3:44 PM Oded Gabbay  wrote:
>
> This is the fourth (and hopefully last) version of the patch-set to add the
> new subsystem for compute accelerators. I removed the RFC headline as
> I believe it is now ready for merging.
>
> Compare to v3, this patch-set contains one additional patch that adds
> documentation regarding the accel subsystem. I hope it's good enough for
> this stage. In addition, there were few very minor fixes according to
> comments received on v3.
>
> The patches are in the following repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
>
> As in v3, The HEAD of that branch is a commit adding a dummy driver that
> registers an accel device using the new framework. This can be served
> as a simple reference.
>
> v1 cover letter:
> https://lkml.org/lkml/2022/10/22/544
>
> v2 cover letter:
> https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/
>
> v3 cover letter:
> https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/
>

With the understanding that individual drivers can choose to use
either classic drm or accel, whichever makes the most sense to them,
this series is:
Acked-by: Alex Deucher 

> Thanks,
> Oded.
>
> Oded Gabbay (4):
>   drivers/accel: define kconfig and register a new major
>   accel: add dedicated minor for accelerator devices
>   drm: initialize accel framework
>   doc: add documentation for accel subsystem
>
>  Documentation/accel/index.rst |  17 ++
>  Documentation/accel/introduction.rst  | 109 +
>  Documentation/admin-guide/devices.txt |   5 +
>  Documentation/subsystem-apis.rst  |   1 +
>  MAINTAINERS   |   9 +
>  drivers/Kconfig   |   2 +
>  drivers/accel/Kconfig |  24 ++
>  drivers/accel/drm_accel.c | 323 ++
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/drm_drv.c | 102 +---
>  drivers/gpu/drm/drm_file.c|   2 +-
>  drivers/gpu/drm/drm_sysfs.c   |  24 +-
>  include/drm/drm_accel.h   |  97 
>  include/drm/drm_device.h  |   3 +
>  include/drm/drm_drv.h |   8 +
>  include/drm/drm_file.h|  21 +-
>  16 files changed, 711 insertions(+), 37 deletions(-)
>  create mode 100644 Documentation/accel/index.rst
>  create mode 100644 Documentation/accel/introduction.rst
>  create mode 100644 drivers/accel/Kconfig
>  create mode 100644 drivers/accel/drm_accel.c
>  create mode 100644 include/drm/drm_accel.h
>
> --
> 2.25.1
>

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Alex Deucher]

On Mon, Nov 21, 2022 at 10:57 AM Alex Deucher  wrote:
>
> On Sat, Nov 19, 2022 at 3:44 PM Oded Gabbay  wrote:
> >
> > This is the fourth (and hopefully last) version of the patch-set to add the
> > new subsystem for compute accelerators. I removed the RFC headline as
> > I believe it is now ready for merging.
> >
> > Compare to v3, this patch-set contains one additional patch that adds
> > documentation regarding the accel subsystem. I hope it's good enough for
> > this stage. In addition, there were few very minor fixes according to
> > comments received on v3.
> >
> > The patches are in the following repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
> >
> > As in v3, The HEAD of that branch is a commit adding a dummy driver that
> > registers an accel device using the new framework. This can be served
> > as a simple reference.
> >
> > v1 cover letter:
> > https://lkml.org/lkml/2022/10/22/544
> >
> > v2 cover letter:
> > https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/
> >
> > v3 cover letter:
> > https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/
> >
>
> With the understanding that individual drivers can choose to use
> either classic drm or accel, whichever makes the most sense to them,
> this series is:
> Acked-by: Alex Deucher 

and not typo my email:
Acked-by: Alex Deucher 

>
> > Thanks,
> > Oded.
> >
> > Oded Gabbay (4):
> >   drivers/accel: define kconfig and register a new major
> >   accel: add dedicated minor for accelerator devices
> >   drm: initialize accel framework
> >   doc: add documentation for accel subsystem
> >
> >  Documentation/accel/index.rst |  17 ++
> >  Documentation/accel/introduction.rst  | 109 +
> >  Documentation/admin-guide/devices.txt |   5 +
> >  Documentation/subsystem-apis.rst  |   1 +
> >  MAINTAINERS   |   9 +
> >  drivers/Kconfig   |   2 +
> >  drivers/accel/Kconfig |  24 ++
> >  drivers/accel/drm_accel.c | 323 ++
> >  drivers/gpu/drm/Makefile  |   1 +
> >  drivers/gpu/drm/drm_drv.c | 102 +---
> >  drivers/gpu/drm/drm_file.c|   2 +-
> >  drivers/gpu/drm/drm_sysfs.c   |  24 +-
> >  include/drm/drm_accel.h   |  97 
> >  include/drm/drm_device.h  |   3 +
> >  include/drm/drm_drv.h |   8 +
> >  include/drm/drm_file.h|  21 +-
> >  16 files changed, 711 insertions(+), 37 deletions(-)
> >  create mode 100644 Documentation/accel/index.rst
> >  create mode 100644 Documentation/accel/introduction.rst
> >  create mode 100644 drivers/accel/Kconfig
> >  create mode 100644 drivers/accel/drm_accel.c
> >  create mode 100644 include/drm/drm_accel.h
> >
> > --
> > 2.25.1
> >

[PATCH resend] drm: mxsfb: DRM_MXSFB should depend on ARCH_MXS || ARCH_MXC

[Geert Uytterhoeven]

Freescale/NXP i.MX LCDIF and eLCDIF LCD controllers are only present on
Freescale/NXP i.MX SoCs.  Hence add a dependency on ARCH_MXS ||
ARCH_MXC, to prevent asking the user about this driver when configuring
a kernel without Freescale/NXP i.MX support.

Fixes: 45d59d704080cc0c ("drm: Add new driver for MXSFB controller")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Marek Vasut 
---
v2:
  - Add Reviewed-by.
---
 drivers/gpu/drm/mxsfb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 116f8168bda4ab1b..70e8b01238cf9079 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -8,6 +8,7 @@ config DRM_MXSFB
tristate "i.MX (e)LCDIF LCD controller"
depends on DRM && OF
depends on COMMON_CLK
+   depends on ARCH_MXS || ARCH_MXC || COMPILE_TEST
select DRM_MXS
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
-- 
2.25.1

[PATCH resend] drm: mxsfb: DRM_IMX_LCDIF should depend on ARCH_MXC

[Geert Uytterhoeven]

The Freescale/NXP i.MX LCDIFv3 LCD controller is only present on
Freescale/NXP i.MX SoCs.  Hence add a dependency on ARCH_MXC, to prevent
asking the user about this driver when configuring a kernel without
Freescale/NXP i.MX support.

Fixes: 9db35bb349a0ef32 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Marek Vasut 
---
v2:
  - Add Reviewed-by.
---
 drivers/gpu/drm/mxsfb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 70e8b01238cf9079..518b533453548630 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -25,6 +25,7 @@ config DRM_IMX_LCDIF
tristate "i.MX LCDIFv3 LCD controller"
depends on DRM && OF
depends on COMMON_CLK
+   depends on ARCH_MXC || COMPILE_TEST
select DRM_MXS
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
-- 
2.25.1

Re: [PATCH resend] drm/armada: Fix off-by-one error in armada_overlay_get_property()

[Russell King (Oracle)]

On Mon, Nov 21, 2022 at 04:43:14PM +0100, Geert Uytterhoeven wrote:
> As ffs() returns one more than the index of the first bit set (zero
> means no bits set), the color key mode value is shifted one position too
> much.
> 
> Fix this by using FIELD_GET() instead.

Reviewed-by: Russell King (Oracle) 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

[Bug 216716] [drm:psp_resume [amdgpu]] *ERROR* PSP resume failed on r9 7950x igpu

[bugzilla-daemon]

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

Artem S. Tashkinov (a...@gmx.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |ANSWERED

--- Comment #1 from Artem S. Tashkinov (a...@gmx.com) ---
Please follow the guidelines and file a report here:

https://gitlab.freedesktop.org/drm/amd/-/issues

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

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

Re: [PATCH] drm: Fix potential null-ptr-deref due to drmm_mode_config_init()

[Thomas Zimmermann]

Hi,

merged into drm-misc-next. Thanks a lot.

Best regards
Thomas

Am 18.11.22 um 03:16 schrieb Shang XiaoJing:

drmm_mode_config_init() will call drm_mode_create_standard_properties()
and won't check the ret value. When drm_mode_create_standard_properties()
failed due to alloc, property will be a NULL pointer and may causes the
null-ptr-deref. Fix the null-ptr-deref by adding the ret value check.

Found null-ptr-deref while testing insert module bochs:
general protection fault, probably for non-canonical address
 0xdc0c:  [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0060-0x0067]
CPU: 3 PID: 249 Comm: modprobe Not tainted 6.1.0-rc1+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:drm_object_attach_property+0x73/0x3c0 [drm]
Call Trace:
  
  __drm_connector_init+0xb6c/0x1100 [drm]
  bochs_pci_probe.cold.11+0x4cb/0x7fe [bochs]
  pci_device_probe+0x17d/0x340
  really_probe+0x1db/0x5d0
  __driver_probe_device+0x1e7/0x250
  driver_probe_device+0x4a/0x120
  __driver_attach+0xcd/0x2c0
  bus_for_each_dev+0x11a/0x1b0
  bus_add_driver+0x3d7/0x500
  driver_register+0x18e/0x320
  do_one_initcall+0xc4/0x3e0
  do_init_module+0x1b4/0x630
  load_module+0x5dca/0x7230
  __do_sys_finit_module+0x100/0x170
  do_syscall_64+0x3f/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7ff65af9f839

Fixes: 6b4959f43a04 ("drm/atomic: atomic plane properties")
Signed-off-by: Shang XiaoJing 
---
  drivers/gpu/drm/drm_mode_config.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 939d621c9ad4..141a5b4042b2 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -402,6 +402,8 @@ static void drm_mode_config_init_release(struct drm_device 
*dev, void *ptr)
   */
  int drmm_mode_config_init(struct drm_device *dev)
  {
+   int ret;
+
mutex_init(&dev->mode_config.mutex);
drm_modeset_lock_init(&dev->mode_config.connection_mutex);
mutex_init(&dev->mode_config.idr_mutex);
@@ -423,7 +425,11 @@ int drmm_mode_config_init(struct drm_device *dev)
init_llist_head(&dev->mode_config.connector_free_list);
INIT_WORK(&dev->mode_config.connector_free_work, 
drm_connector_free_work_fn);
  
-	drm_mode_create_standard_properties(dev);

+   ret = drm_mode_create_standard_properties(dev);
+   if (ret) {
+   drm_mode_config_cleanup(dev);
+   return ret;
+   }
  
  	/* Just to be sure */

dev->mode_config.num_fb = 0;


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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2 3/3] drm/gem-shmem: When drm_gem_object_init failed, should release object

[Thomas Zimmermann]

Hi

Am 19.11.22 um 07:41 schrieb ChunyouTang:

when goto err_free, the object had init, so it should be release when fail.

Signed-off-by: ChunyouTang 


Thanks a lot. I merged the patch into drm-misc-next.

Best regards
Thomas


---
  drivers/gpu/drm/drm_gem.c  | 19 ---
  drivers/gpu/drm/drm_gem_shmem_helper.c |  4 +++-
  include/drm/drm_gem.h  |  1 +
  3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 8b68a3c1e6ab..3e2e660717c3 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -169,6 +169,20 @@ void drm_gem_private_object_init(struct drm_device *dev,
  }
  EXPORT_SYMBOL(drm_gem_private_object_init);
  
+/**

+ * drm_gem_private_object_fini - Finalize a failed drm_gem_object
+ * @obj: drm_gem_object
+ *
+ * Uninitialize an already allocated GEM object when it initialized failed
+ */
+void drm_gem_private_object_fini(struct drm_gem_object *obj)
+{
+   WARN_ON(obj->dma_buf);
+
+   dma_resv_fini(&obj->_resv);
+}
+EXPORT_SYMBOL(drm_gem_private_object_fini);
+
  /**
   * drm_gem_object_handle_free - release resources bound to userspace handles
   * @obj: GEM object to clean up.
@@ -930,12 +944,11 @@ drm_gem_release(struct drm_device *dev, struct drm_file 
*file_private)
  void
  drm_gem_object_release(struct drm_gem_object *obj)
  {
-   WARN_ON(obj->dma_buf);
-
if (obj->filp)
fput(obj->filp);
  
-	dma_resv_fini(&obj->_resv);

+   drm_gem_private_object_fini(obj);
+
drm_gem_free_mmap_offset(obj);
drm_gem_lru_remove(obj);
  }
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 35138f8a375c..db73234edcbe 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -79,8 +79,10 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size, 
bool private)
} else {
ret = drm_gem_object_init(dev, obj, size);
}
-   if (ret)
+   if (ret) {
+   drm_gem_private_object_fini(obj);
goto err_free;
+   }
  
  	ret = drm_gem_create_mmap_offset(obj);

if (ret)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index bd42f25e449c..9b1feb03069d 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -405,6 +405,7 @@ int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
  void drm_gem_private_object_init(struct drm_device *dev,
 struct drm_gem_object *obj, size_t size);
+void drm_gem_private_object_fini(struct drm_gem_object *obj);
  void drm_gem_vm_open(struct vm_area_struct *vma);
  void drm_gem_vm_close(struct vm_area_struct *vma);
  int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,


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


OpenPGP_signature
Description: OpenPGP digital signature

Re: git send-email friendly smtp provider anyone?

[Noralf Trønnes]

Den 21.11.2022 14.33, skrev Simon Ser:
> I think you can apply for a linux.dev mailbox [1].
> 

Yeah you're right, I didn't know about that possibility.
But it depends on whether or not I can just use their smtp server and
keep my current email address. This looks like what's the problem with
my current ISP, I need to use the email account I have in their email
service (that I've never used) for sending through their smtp server,
but I want to send From: another email address.

Noralf.

> [1]: https://korg.docs.kernel.org/linuxdev.html

Re: git send-email friendly smtp provider anyone?

[Simon Ser]

On Monday, November 21st, 2022 at 17:52, Noralf Trønnes  
wrote:

> Den 21.11.2022 14.33, skrev Simon Ser:
> 
> > I think you can apply for a linux.dev mailbox 1.
> 
> Yeah you're right, I didn't know about that possibility.
> But it depends on whether or not I can just use their smtp server and
> keep my current email address. This looks like what's the problem with
> my current ISP, I need to use the email account I have in their email
> service (that I've never used) for sending through their smtp server,
> but I want to send From: another email address.

That's not possible. It breaks DKIM, so your emails will end up in Spam
folders or be rejected. You need to use the SMTP server tied to your
email address.

Re: git send-email friendly smtp provider anyone?

[Simon Ser]

On Monday, November 21st, 2022 at 18:02, Simon Ser  wrote:

> On Monday, November 21st, 2022 at 17:52, Noralf Trønnes nor...@tronnes.org 
> wrote:
> 
> > Den 21.11.2022 14.33, skrev Simon Ser:
> > 
> > > I think you can apply for a linux.dev mailbox 1.
> > 
> > Yeah you're right, I didn't know about that possibility.
> > But it depends on whether or not I can just use their smtp server and
> > keep my current email address. This looks like what's the problem with
> > my current ISP, I need to use the email account I have in their email
> > service (that I've never used) for sending through their smtp server,
> > but I want to send From: another email address.
> 
> That's not possible. It breaks DKIM, so your emails will end up in Spam
> folders or be rejected. You need to use the SMTP server tied to your
> email address.

That said, you can send patches from an email address different from
the one in your patches. IOW, you can send patches committed by
 from any email account.

The From in the email header won't match the commit, but the very first
line of the patch will hold that information.

Re: [PATCH] drm/amdgpu: fix unused-function error

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Nov 21, 2022 at 8:09 AM Ren Zhijie  wrote:
>
> If CONFIG_DRM_AMDGPU=y and CONFIG_DRM_AMD_DC is not set,
> gcc complained about unused-function :
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1705:13: error: 
> ‘amdgpu_discovery_set_sriov_display’ defined but not used 
> [-Werror=unused-function]
>  static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
>  ^~
> cc1: all warnings being treated as errors
>
> To fix this error, use CONFIG_DRM_AMD_DC to wrap
> the definition of amdgpu_discovery_set_sriov_display().
>
> Fixes: 25263da37693 ("drm/amdgpu: rework SR-IOV virtual display handling")
> Signed-off-by: Ren Zhijie 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index 6b48178455bc..2509341df92d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -1702,11 +1702,13 @@ static int amdgpu_discovery_set_smu_ip_blocks(struct 
> amdgpu_device *adev)
> return 0;
>  }
>
> +#if defined(CONFIG_DRM_AMD_DC)
>  static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
>  {
> amdgpu_device_set_sriov_virtual_display(adev);
> amdgpu_device_ip_block_add(adev, &amdgpu_vkms_ip_block);
>  }
> +#endif
>
>  static int amdgpu_discovery_set_display_ip_blocks(struct amdgpu_device *adev)
>  {
> --
> 2.17.1
>

[PATCH] drm/amdgpu: Partially revert "drm/amdgpu: update drm_display_info correctly when the edid is read"

[Alex Deucher]

This partially reverts 20543be93ca45968f344261c1a997177e51bd7e1.

Calling drm_connector_update_edid_property() in
amdgpu_connector_free_edid() causes a noticable pause in
the system every 10 seconds on polled outputs so revert this
part of the change.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2257
Cc: Claudio Suarez 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 491d4846fc02..cfb262911bfc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -328,7 +328,6 @@ static void amdgpu_connector_free_edid(struct drm_connector 
*connector)
 
kfree(amdgpu_connector->edid);
amdgpu_connector->edid = NULL;
-   drm_connector_update_edid_property(connector, NULL);
 }
 
 static int amdgpu_connector_ddc_get_modes(struct drm_connector *connector)
-- 
2.38.1

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Fix negative value passed as remaining time

[Andrzej Hajda]

On 21.11.2022 15:56, Janusz Krzysztofik wrote:

Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
with GuC") extended the API of intel_gt_retire_requests_timeout() with an
extra argument 'remaining_timeout', intended for passing back unconsumed
portion of requested timeout when 0 (success) is returned.  However, when
request retirement happens to succeed despite an error returned by a call
to dma_fence_wait_timeout(), that error code (a negative value) is passed
back instead of remaining time.  If we then pass that negative value
forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG
will be triggered.

If request retirement succeeds but an error code is passed back via
remaininig_timeout, we may have no clue on how much of the initial timeout
might have been left for spending it on waiting for GuC to become idle.
OTOH, since all pending requests have been successfully retired, that
error code has been already ignored by intel_gt_retire_requests_timeout(),
then we shouldn't fail.

Assume no more time has been left on error and pass 0 timeout value to
intel_uc_wait_for_idle() to give it a chance to return success if GuC is
already idle.

v3: Don't fail on any error passed back via remaining_timeout.

v2: Fix the issue on the caller side, not the provider.

Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with 
GuC")
Signed-off-by: Janusz Krzysztofik 
Cc: sta...@vger.kernel.org # v5.15+


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


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

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b5ad9caa55372..7ef0edb2e37cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -677,8 +677,13 @@ int intel_gt_wait_for_idle(struct intel_gt *gt, long 
timeout)
return -EINTR;
}
  
-	return timeout ? timeout : intel_uc_wait_for_idle(>->uc,

- remaining_timeout);
+   if (timeout)
+   return timeout;
+
+   if (remaining_timeout < 0)
+   remaining_timeout = 0;
+
+   return intel_uc_wait_for_idle(>->uc, remaining_timeout);
  }
  
  int intel_gt_init(struct intel_gt *gt)

Re: [PATCH] [next] drm/amdgpu: Replace remaining 1-element array with flex-array

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Nov 21, 2022 at 2:26 AM Paulo Miguel Almeida
 wrote:
>
> One-element arrays are deprecated, and we are replacing them with
> flexible array members instead. So, replace one-element array with
> flexible-array member in struct GOP_VBIOS_CONTENT and refactor the
> rest of the code accordingly.
>
> Important to mention is that doing a build before/after this patch
> results in no functional binary output differences.
>
> This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
> routines on memcpy() and help us make progress towards globally
> enabling -fstrict-flex-arrays=3 [1].
>
> Link: https://github.com/KSPP/linux/issues/79
> Link: https://github.com/KSPP/linux/issues/238
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1]
>
> Signed-off-by: Paulo Miguel Almeida 
> ---
> This should be the last one-element array that had references in source
> code. Given the way it was used, no *.c code change was required.
>
> I will move on to the atombios.h in the radeon driver.
> ---
>  drivers/gpu/drm/amd/include/atombios.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/include/atombios.h 
> b/drivers/gpu/drm/amd/include/atombios.h
> index 4dc738c51771..b78360a71bc9 100644
> --- a/drivers/gpu/drm/amd/include/atombios.h
> +++ b/drivers/gpu/drm/amd/include/atombios.h
> @@ -9292,7 +9292,7 @@ typedef struct {
>
>  typedef struct {
>VFCT_IMAGE_HEADER   VbiosHeader;
> -  UCHAR   VbiosContent[1];
> +  UCHAR   VbiosContent[];
>  }GOP_VBIOS_CONTENT;
>
>  typedef struct {
> --
> 2.37.3
>

Re: git send-email friendly smtp provider anyone?

[Noralf Trønnes]

Den 21.11.2022 18.06, skrev Simon Ser:
> On Monday, November 21st, 2022 at 18:02, Simon Ser  
> wrote:
> 
>> On Monday, November 21st, 2022 at 17:52, Noralf Trønnes nor...@tronnes.org 
>> wrote:
>>
>>> Den 21.11.2022 14.33, skrev Simon Ser:
>>>
 I think you can apply for a linux.dev mailbox 1.
>>>
>>> Yeah you're right, I didn't know about that possibility.
>>> But it depends on whether or not I can just use their smtp server and
>>> keep my current email address. This looks like what's the problem with
>>> my current ISP, I need to use the email account I have in their email
>>> service (that I've never used) for sending through their smtp server,
>>> but I want to send From: another email address.
>>
>> That's not possible. It breaks DKIM, so your emails will end up in Spam
>> folders or be rejected. You need to use the SMTP server tied to your
>> email address.
> 
> That said, you can send patches from an email address different from
> the one in your patches. IOW, you can send patches committed by
>  from any email account.
> 
> The From in the email header won't match the commit, but the very first
> line of the patch will hold that information.

Thanks that was useful information. I've seen the DKIM abbr. but haven't
looked into the meaning of it.

I tried:

git send-email --from=noralf.tron...@altiboxmail.no
--reply=nor...@tronnes.org

and now I'm getting 'pass' in the Authentication-Results field, so
that's progress. I'm still not getting all the emails through, so I
still have that problem, I'll have to wait and see what the ISP can tell me.

But this means that a linux.dev mailbox is an option for me should my
ISP be a blocker.

Noralf.

Re: [PATCH v3] drm/i915/mtl: Enable Idle Messaging for GSC CS

[Vivi, Rodrigo]

On Fri, 2022-11-18 at 13:37 -0800, Dixit, Ashutosh wrote:
> On Fri, 18 Nov 2022 10:37:37 -0800, Vivi, Rodrigo wrote:
> > 
> > On Sat, 2022-11-19 at 00:03 +0530, Badal Nilawar wrote:
> > > From: Vinay Belgaumkar 
> > > 
> > > By defaut idle messaging is disabled for GSC CS so to unblock RC6
> > > entry on media tile idle messaging need to be enabled.
> > > 
> > > v2:
> > >  - Fix review comments (Vinay)
> > >  - Set GSC idle hysteresis as per spec (Badal)
> > > v3:
> > >  - Fix review comments (Rodrigo)
> > > 
> > > Bspec: 71496
> > > 
> > > Cc: Daniele Ceraolo Spurio 
> > > Signed-off-by: Vinay Belgaumkar 
> > > Signed-off-by: Badal Nilawar 
> > > Reviewed-by: Vinay Belgaumkar 
> > 
> > He is the author of the patch, no?!
> > or you can remove this or change the author to be you and keep his
> > reviewed-by...
> > 
> > or I can just remove his rv-b while merging.. just let me know..
> 
> Not sure if that is the case here,

yeap, this is too small patch for that to happen.

>  but when multiple people contribute to a
> patch, the original author can review changes by others and add his
> Reviewed-by, no? Or are we saying it is redundant for the author to
> add his
> R-b?
> 
> Similarly, are S-o-b and R-b by the same person ok? I add changes to
> someone's patch so add my S-o-b but also review other's changes so
> add my
> R-b? Sometimes finding a 3rd person to add a R-b is hard. But two
> poeple
> can contribute to a patch and review each other's changes so add both
> their
> S-o-b's and R-b's or no?

Definitely a case by case thing. If that happens it is good to have it
clearly written in the commit message to know who did what, who
reviewed what.

Although I'd say that I'd still prefer the co-authored-by and having a
third one doing the full review.

> 
> :)
> 
> Ashutosh
> 

Re: [PATCH v3] drm/i915/mtl: Enable Idle Messaging for GSC CS

[Vivi, Rodrigo]

On Sat, 2022-11-19 at 09:02 +0530, Nilawar, Badal wrote:
> 
> 
> On 19-11-2022 00:07, Vivi, Rodrigo wrote:
> > On Sat, 2022-11-19 at 00:03 +0530, Badal Nilawar wrote:
> > > From: Vinay Belgaumkar 
> > > 
> > > By defaut idle messaging is disabled for GSC CS so to unblock RC6
> > > entry on media tile idle messaging need to be enabled.
> > > 
> > > v2:
> > >   - Fix review comments (Vinay)
> > >   - Set GSC idle hysteresis as per spec (Badal)
> > > v3:
> > >   - Fix review comments (Rodrigo)
> > > 
> > > Bspec: 71496
> > > 
> > > Cc: Daniele Ceraolo Spurio 
> > > Signed-off-by: Vinay Belgaumkar 
> > > Signed-off-by: Badal Nilawar 
> > > Reviewed-by: Vinay Belgaumkar 
> > 
> > He is the author of the patch, no?!
> > or you can remove this or change the author to be you and keep his
> > reviewed-by...
> > 
> > or I can just remove his rv-b while merging.. just let me know..
> As he is original author I will prefer not to change it. You can
> remove 
> his rv-b while merging.

Thanks and pushed.

> 
> Regards,
> Badal
> > 
> > > Reviewed-by: Rodrigo Vivi 
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18
> > > ++
> > >   drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  4 
> > >   2 files changed, 22 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > index b0a4a2dbe3ee..e971b153fda9 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > @@ -15,6 +15,22 @@
> > >   #include "intel_rc6.h"
> > >   #include "intel_ring.h"
> > >   #include "shmem_utils.h"
> > > +#include "intel_gt_regs.h"
> > > +
> > > +static void intel_gsc_idle_msg_enable(struct intel_engine_cs
> > > *engine)
> > > +{
> > > +   struct drm_i915_private *i915 = engine->i915;
> > > +
> > > +   if (IS_METEORLAKE(i915) && engine->id == GSC0) {
> > > +   intel_uncore_write(engine->gt->uncore,
> > > +  RC_PSMI_CTRL_GSCCS,
> > > +
> > > _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
> > > +   /* hysteresis 0xA=5us as recommended in spec*/
> > > +   intel_uncore_write(engine->gt->uncore,
> > > +  PWRCTX_MAXCNT_GSCCS,
> > > +  0xA);
> > > +   }
> > > +}
> > >   
> > >   static void dbg_poison_ce(struct intel_context *ce)
> > >   {
> > > @@ -275,6 +291,8 @@ void intel_engine_init__pm(struct
> > > intel_engine_cs
> > > *engine)
> > >   
> > >  intel_wakeref_init(&engine->wakeref, rpm, &wf_ops);
> > >  intel_engine_init_heartbeat(engine);
> > > +
> > > +   intel_gsc_idle_msg_enable(engine);
> > >   }
> > >   
> > >   /**
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > index c3cd92691795..80a979e6f6be 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > @@ -917,6 +917,10 @@
> > >   #define  MSG_IDLE_FW_MASK  REG_GENMASK(13, 9)
> > >   #define  MSG_IDLE_FW_SHIFT 9
> > >   
> > > +#defineRC_PSMI_CTRL_GSCCS  _MMIO(0x11a050)
> > > +#define  IDLE_MSG_DISABLE  REG_BIT(0)
> > > +#definePWRCTX_MAXCNT_GSCCS _MMIO(0x11a054)
> > > +
> > >   #define FORCEWAKE_MEDIA_GEN9   _MMIO(0xa270)
> > >   #define FORCEWAKE_RENDER_GEN9  _MMIO(0xa278)
> > >   
> > 

Re: git send-email friendly smtp provider anyone?

[Noralf Trønnes]

Den 21.11.2022 16.19, skrev Maxime Ripard:
> On Mon, Nov 21, 2022 at 12:48:52PM +0100, Noralf Trønnes wrote:
>> A couple of years ago my email provider blocked me from using git
>> send-email with their smtp server. So I switched to the one my ISP
>> provides. Now my ISP have outsourced their email service so the first 3
>> emails gets through and the rest looks like it ends up in a tar pit or
>> something, 18 hours later and 5 of 7 emails have gotten through. I have
>> asked them about this, but I fear the answer will be this is not
>> supported since they now don't have the service in-house anymore. I'm
>> waiting for a reply.
>>
>> Today I tried sendinblue.com since they have a free plan, but they
>> insert  in the emails so that didn't work out. They also have some
>> kind of queue, after 1 hour 6 of 7 emails have gotten through.
>>
>> Does anyone have an smtp provider to recommend that works with git
>> send-email and that sends out all the emails at once?
> 
> I'm using fastmail and am very happy about it so far.
> 
> Otherwise, you might consider using:
> https://b4.docs.kernel.org/en/latest/contributor/send.html#authenticating-with-the-web-submission-endpoint
> 

That's an interesting option. I did briefly look at b4 a few months back
but it looked like it was under heavy development so I figured I'd wait
before trying it out. I think I'll give b4 a spin to see how it works, I
wonder how it handles patch changelogs.

Noralf.

[PATCH] drm: rcar-du: Fix Kconfig dependency between DRM and RZG2L_MIPI_DSI

[Biju Das]

When CONFIG_DRM=m and CONFIG_DRM_RZG2L_MIPI_DSI=y, it results in a
build failure. This patch fixes the build issue by adding dependency
to DRM.

Fixes: 7a043f978ed1 ("drm: rcar-du: Add RZ/G2L DSI driver")
Reported-by: kernel test robot 
Signed-off-by: Biju Das 
---
Ref:
 * 
https://lore.kernel.org/linux-renesas-soc/os0pr01mb592298e75153a52245d789d486...@os0pr01mb5922.jpnprd01.prod.outlook.com/T/#u
---
 drivers/gpu/drm/rcar-du/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1065dca885ef..b2bddbeca878 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -56,7 +56,7 @@ config DRM_RCAR_MIPI_DSI
 
 config DRM_RZG2L_MIPI_DSI
tristate "RZ/G2L MIPI DSI Encoder Support"
-   depends on DRM_BRIDGE && OF
+   depends on DRM && DRM_BRIDGE && OF
depends on ARCH_RENESAS || COMPILE_TEST
select DRM_MIPI_DSI
help
-- 
2.25.1

Re: [Intel-gfx] [PATCH v2 0/5] Add module oriented dmesg output

[John Harrison]

On 11/18/2022 02:52, Jani Nikula wrote:

On Thu, 17 Nov 2022, john.c.harri...@intel.com wrote:

From: John Harrison 

When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a GT# prefix on it.

It was also requested to extend this further to submodules in order to
factor out the repeated structure accessing constructs and common
string prefixes. So, add versions for GuC, HuC and GuC CTB as well.

This patch set updates all the gt/uc files to use the new helpers as a
first step. The intention would be to convert all output messages that
have access to a GT structure.

v2: Go back to using lower case names, add more wrapper sets (combined
review feedback). Also, wrap up probe injection and WARN entries.

Signed-off-by: John Harrison 

For adding the wrappers in general, I'm going to disagree and
commit. I'll leave it up to Tvrtko and Joonas.

Regarding the placement of the macros, I insist you add individual
header files for the wrappers and include them only where needed.

We have a fairly serious problem with everything including everything in
i915 that I've been slowly trying to tackle. Touch one thing, rebuild
everything. About a third of our headers cause the rebuild of the entire
driver when modified. We need to reduce the surface of things that cause
rebuilds.

For example, intel_gt.h is included by 97 files, intel_guc.h by 332
files, and intel_huc.h by 329 files (counting recursively).

There's absolutely no reason any of the display code, for example, needs
to have these logging macros in their build. Long term, the headers
should be reorganized to reduce the interdependencies, and this is what
I've been doing in i915_drv.h and display/ in general. But the least we
can do is not make the problem worse.
@Tvrtko/@Michal W, any other review comments or feedback? I'd rather not 
spend time fixing up the header file issue and reposting only to have 
someone point out another issue that could have been resolved at the 
same time.


John.


BR,
Jani.



John Harrison (5):
   drm/i915/gt: Start adding module oriented dmesg output
   drm/i915/huc: Add HuC specific debug print wrappers
   drm/i915/guc: Add GuC specific debug print wrappers
   drm/i915/guc: Add GuC CT specific debug print wrappers
   drm/i915/uc: Update the gt/uc code to use gt_err and friends

  drivers/gpu/drm/i915/gt/intel_gt.c|  96 
  drivers/gpu/drm/i915/gt/intel_gt.h|  35 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc.c|  32 +--
  drivers/gpu/drm/i915/gt/uc/intel_guc.h|  35 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|   8 +-
  .../gpu/drm/i915/gt/uc/intel_guc_capture.c|  48 ++--
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 222 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |  19 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  37 ++-
  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c |   7 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  55 ++---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  62 +++--
  drivers/gpu/drm/i915/gt/uc/intel_huc.c|  31 +--
  drivers/gpu/drm/i915/gt/uc/intel_huc.h|  23 ++
  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 108 -
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  98 
  drivers/gpu/drm/i915/gt/uc/selftest_guc.c |  34 +--
  .../drm/i915/gt/uc/selftest_guc_hangcheck.c   |  22 +-
  .../drm/i915/gt/uc/selftest_guc_multi_lrc.c   |  10 +-
  19 files changed, 507 insertions(+), 475 deletions(-)

Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()

[Christian König]

Hi Dawei,

from the technical description, coding style etc.. it looks clean to me, 
but I'm the completely wrong person to ask for a background check.


I have a high level understanding of how dma-heaps work, but not a 
single line of this code is from me.


Feel free to add my Acked-by, but Laura, John and others do you have any 
opinion?


Regards,
Christian.

Am 21.11.22 um 16:28 schrieb Dawei Li:

On Sat, Nov 05, 2022 at 12:05:36AM +0800, Dawei Li wrote:

Hi Christian,
May I have your opinion on this change?

Thanks,
Dawei


Racing conflict could be:
task A task B
list_for_each_entry
strcmp(h->name))
list_for_each_entry
strcmp(h->name)
kzallockzalloc
.. .
device_create  device_create
list_add
list_add

The root cause is that task B has no idea about the fact someone
else(A) has inserted heap with same name when it calls list_add,
so a potential collision occurs.

Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
Signed-off-by: Dawei Li 
---
v1: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2FTYCP286MB2323950197F60FC3473123B7CA349%40TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C1989f31257fc458a27c508dacbd5078e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046413707443203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OWPUPrIHGnzwXyQE4WlIthThwSuSK2y3Eq2Wq5zAzbo%3D&reserved=0
v1->v2: Narrow down locking scope, check the existence of heap before
insertion, as suggested by Andrew Davis.
v2->v3: Remove double checking.
v3->v4: Minor coding style and patch formatting adjustment.
---
  drivers/dma-buf/dma-heap.c | 28 +++-
  1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 8f5848aa144f..59d158873f4c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
  
-	/* check the name is unique */

-   mutex_lock(&heap_list_lock);
-   list_for_each_entry(h, &heap_list, list) {
-   if (!strcmp(h->name, exp_info->name)) {
-   mutex_unlock(&heap_list_lock);
-   pr_err("dma_heap: Already registered heap named %s\n",
-  exp_info->name);
-   return ERR_PTR(-EINVAL);
-   }
-   }
-   mutex_unlock(&heap_list_lock);
-
heap = kzalloc(sizeof(*heap), GFP_KERNEL);
if (!heap)
return ERR_PTR(-ENOMEM);
@@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
err_ret = ERR_CAST(dev_ret);
goto err2;
}
-   /* Add heap to the list */
+
mutex_lock(&heap_list_lock);
+   /* check the name is unique */
+   list_for_each_entry(h, &heap_list, list) {
+   if (!strcmp(h->name, exp_info->name)) {
+   mutex_unlock(&heap_list_lock);
+   pr_err("dma_heap: Already registered heap named %s\n",
+  exp_info->name);
+   err_ret = ERR_PTR(-EINVAL);
+   goto err3;
+   }
+   }
+
+   /* Add heap to the list */
list_add(&heap->list, &heap_list);
mutex_unlock(&heap_list_lock);
  
  	return heap;
  
+err3:

+   device_destroy(dma_heap_class, heap->heap_devt);
  err2:
cdev_del(&heap->heap_cdev);
  err1:
--
2.25.1

Re: [PATCH v13,2/3] drm: mediatek: Set dpi format in mmsys

[Matthias Brugger]

On 24/10/2022 04:04, xinlei@mediatek.com wrote:

From: Xinlei Lee 

Dpi output needs to adjust the output format to dual edge for MT8186.

Co-developed-by: Jitao Shi 
Signed-off-by: Jitao Shi 
Signed-off-by: Xinlei Lee 
Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: Nícolas F. R. A. Prado 


I realized that I took this patch by error. I'll drop it from my tree now.

Regards,
Matthias


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

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 630a4e301ef6..ad87ecddf58d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include 

@@ -30,6 +31,7 @@
  #include "mtk_disp_drv.h"
  #include "mtk_dpi_regs.h"
  #include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
  
  enum mtk_dpi_out_bit_num {

MTK_DPI_OUT_BIT_NUM_8BITS,
@@ -67,6 +69,7 @@ struct mtk_dpi {
struct drm_connector *connector;
void __iomem *regs;
struct device *dev;
+   struct device *mmsys_dev;
struct clk *engine_clk;
struct clk *pixel_clk;
struct clk *tvd_clk;
@@ -135,6 +138,7 @@ struct mtk_dpi_yc_limit {
   * @yuv422_en_bit: Enable bit of yuv422.
   * @csc_enable_bit: Enable bit of CSC.
   * @pixels_per_iter: Quantity of transferred pixels per iteration.
+ * @edge_cfg_in_mmsys: If the edge configuration for DPI's output needs to be 
set in MMSYS.
   */
  struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
@@ -153,6 +157,7 @@ struct mtk_dpi_conf {
u32 yuv422_en_bit;
u32 csc_enable_bit;
u32 pixels_per_iter;
+   bool edge_cfg_in_mmsys;
  };
  
  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)

@@ -449,8 +454,12 @@ static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING,
 dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_LE ?
 EDGE_SEL : 0, EDGE_SEL);
+   if (dpi->conf->edge_cfg_in_mmsys)
+   mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev, 
MTK_DPI_RGB888_DDR_CON);
} else {
mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE, 0);
+   if (dpi->conf->edge_cfg_in_mmsys)
+   mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev, 
MTK_DPI_RGB888_SDR_CON);
}
  }
  
@@ -778,8 +787,10 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)

  {
struct mtk_dpi *dpi = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+   struct mtk_drm_private *priv = drm_dev->dev_private;
int ret;
  
+	dpi->mmsys_dev = priv->mmsys_dev;

ret = drm_simple_encoder_init(drm_dev, &dpi->encoder,
  DRM_MODE_ENCODER_TMDS);
if (ret) {

Re: [PATCH v10 18/19] drm/vc4: vec: Add support for more analog TV standards

[Mateusz Kwiatkowski]

Hi Mauro,

As the author of the original version of this commit, and also a person who
argued quite a bit on these descriptions and decisions, let me chip in a bit.

W dniu 17.11.2022 o 16:49, Mauro Carvalho Chehab pisze:
> On Thu, 17 Nov 2022 10:29:01 +0100
> Maxime Ripard  wrote:
>
>> From: Mateusz Kwiatkowski 
>>
>> Add support for the following composite output modes (all of them are
>> somewhat more obscure than the previously defined ones):
>>
>> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
>>   4.43361875 MHz (the PAL subcarrier frequency). Never used for
>>   broadcasting, but sometimes used as a hack to play NTSC content in PAL
>>   regions (e.g. on VCRs).
>
>> - PAL_N - PAL with alternative chroma subcarrier frequency,
>>   3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
>>   and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
>
> That's not right. Argentina uses a different standard than Paraguay and
> Uruguai.
>
> See, there are two variants of PAL/N. The original one and PAL/N' - also
> called PAL/NC or PAL/CN (Combination N). Some of the timings are 
> different on /NC variant.
>
> As far as I'm aware, PAL/Nc is used in Argentina, while
> PAL/N is used in Paraguai and Uruguai, but I may be wrong on that,
> as it has been a long time since had to touch on this.

If you say so - maybe that's true. But I tried to find any differences between
PAL-N and PAL-Nc many times and haven't found anything concrete. The only
authoritative source where System N and "Combination N/PAL" seem to be mentioned
as separate entities is BT.1701
. However:

a) the differences are very subtle (with "combination N/PAL" being just a tad
   stricter than what's mentioned for System N)
b) "Combination N/PAL" can be understood as just "System N combined with PAL
   color", as opposed to "raw", black&white System N. This intepretation is also
   what the user calling themselves "Alcahemist" suggests here:
   https://en.wikipedia.org/wiki/Talk:PAL#PAL-N_versus_PAL-Nc

This is of course far from an authoritative source. If you have a definitive
source for PAL-N and PAL-Nc being different, or concrete information on what is
different between them specifically, then so be it. But I tried and haven't
found anything conclusive.

>> - PAL60 - 480i60 signal with PAL-style color at normal European PAL
>>   frequency. Another non-standard, non-broadcast mode, used in similar
>>   contexts as NTSC_443. Some displays support one but not the other.
>
>> - SECAM - French frequency-modulated analog color standard; also have
>>   been broadcast in Eastern Europe and various parts of Africa and Asia.
>>   Uses the same 576i50 timings as PAL.
>
> This is also wrong. just like PAL, there are several variants of SECAM,
> one used in France, and a different one in France overseas and on
> previous France colonies in Africa and Asia. Eastern Europe also used
> different variants of SECAM.

This is true. However, those differed only in RF modulation. For example,
French SECAM-L used positive video modulation and AM sound, while Eastern
European SECAM-D/K used negative video modulation and FM sound. But the
baseband composite signals were identical.

There were several other variants of SECAM, like early SECAM/V vs. SECAM/H
("Field identification" vs. "Line identification") which moved the color
identification signals from VBI to HBI. But that's a change that all SECAM
regions, including both France and Eastern Europe did in the 1980s to
acommodate for teletext. Again, authoritative sources are scarce, but see e.g.
https://web.archive.org/web/20160303232903/http://www.pembers.freeserve.co.uk/World-TV-Standards/Colour-Standards.html
(search for "Synchronisation of SECAM colour transmissions" on the page).

There's also MESECAM, but that only applies to encoding on VHS and Betamax
tapes, not the signals themselves. There was also SECAM-M for 525-line (480i)
signals, but I haven't found any conclusive evidence that it was ever used for
broadcast anywhere

So yeah, SECAM can be a bit confusing, but AFAIK there's only one standard if
we're talking about the composite video layer.

--

Some *really* old (like, 1960s old) versions of CCIR documents also listed more
substantial differences between various 625-line systems, including the number
of active lines varying from 571 to 589. But all revisions from 1974 onward list
the modern value of 575 active lines for all the variants, making them differ
only in RF modulation details. Which is beyond the scope of what the "TV mode"
property is supposed to do.

>> Also added some comments explaining color subcarrier frequency
>> registers.
>>
>> Acked-by: Noralf Trønnes 
>> Signed-off-by: Mateusz Kwiatkowski 
>> Tested-by: Mateusz Kwiatkowski 
>> Signed-off-by: Maxime Ripard 
>>
>> ---
>> Changes in v6:
>> - Support PAL60 again
>> ---
>>  drivers/gpu/drm/vc4/vc4_vec.c | 111 
>> ++

Re: [PATCH v3 2/6] dt-bindings: Use new video interface bus type macros in examples

[Sakari Ailus]

Hi Laurent,

On Sat, Jul 16, 2022 at 06:12:05PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Sat, Jul 16, 2022 at 12:28:45PM +0300, Sakari Ailus wrote:
> > On Thu, Jun 16, 2022 at 01:14:06AM +0300, Laurent Pinchart wrote:
> > > Now that a header exists with macros for the media interface bus-type
> > > values, replace hardcoding numerical constants with the corresponding
> > > macros in the DT binding examples.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > > Changes since v2:
> > > 
> > > - Go back to PARALLEL
> > > 
> > > Changes since v1:
> > > 
> > > - Rename PARALLEL to BT601
> > > ---
> > >  .../devicetree/bindings/display/bridge/analogix,anx7625.yaml  | 1 +
> > >  Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml | 3 ++-
> > >  Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml  | 3 ++-
> > >  .../devicetree/bindings/media/marvell,mmp2-ccic.yaml  | 3 ++-
> > >  Documentation/devicetree/bindings/media/microchip,xisc.yaml   | 3 ++-
> > >  Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml| 4 +++-
> > >  6 files changed, 12 insertions(+), 5 deletions(-)
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index 35a48515836e..b0e5585f93e2 100644
> > > --- 
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++ 
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -118,6 +118,7 @@ additionalProperties: false
> > >  examples:
> > >- |
> > >  #include 
> > > +#include 
> > >  
> > >  i2c0 {
> > >  #address-cells = <1>;
> > 
> > The definition doesn't seem to be used here. Is there a need to include
> > this?
> 
> There was, but the change that added bus-type to this binding got
> reverted in commit 979452fbc430 ("dt-bindings: drm/bridge: anx7625:
> Revert DPI support") and I forgot to drop the header when rebasing.
> 
> > I could drop this chunk while applying. There's just one trivial change
> > elsewhere in this patch to make.
> 
> Please do :-)

Applied with the following diff:

diff --git 
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 7fa7a667c764a..4590186c4a0b8 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -133,7 +133,6 @@ additionalProperties: false
 examples:
   - |
 #include 
-#include 
 
 i2c0 {
 #address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml 
b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index 285c6075950ad..e80fcdf280f0b 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -92,7 +92,7 @@ examples:
 #include 
 #include 
 #include 
-#
+
 dcmi: dcmi@4c006000 {
 compatible = "st,stm32-dcmi";
 reg = <0x4c006000 0x400>;

It seems that there's also bus-type 7 that corresponds to MIPI DPI. Could
you add a macro for this one as well? :-) In particular it's used by
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml .

-- 
Kind regards,

Sakari Ailus

Re: [PATCH] drm/amdgpu: Partially revert "drm/amdgpu: update drm_display_info correctly when the edid is read"

[Luben Tuikov]

Acked-by: Luben Tuikov 

Regards,
Luben

On 2022-11-21 12:38, Alex Deucher wrote:
> This partially reverts 20543be93ca45968f344261c1a997177e51bd7e1.
> 
> Calling drm_connector_update_edid_property() in
> amdgpu_connector_free_edid() causes a noticable pause in
> the system every 10 seconds on polled outputs so revert this
> part of the change.
> 
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2257
> Cc: Claudio Suarez 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 491d4846fc02..cfb262911bfc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -328,7 +328,6 @@ static void amdgpu_connector_free_edid(struct 
> drm_connector *connector)
>  
>   kfree(amdgpu_connector->edid);
>   amdgpu_connector->edid = NULL;
> - drm_connector_update_edid_property(connector, NULL);
>  }
>  
>  static int amdgpu_connector_ddc_get_modes(struct drm_connector *connector)

[linux-next:master] BUILD REGRESSION e4cd8d3ff7f9efeb97330e5e9b99eeb2a68f5cf9

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: e4cd8d3ff7f9efeb97330e5e9b99eeb2a68f5cf9  Add linux-next specific 
files for 20221121

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202211130053.np70vidn-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211191949.jqnwetuw-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211200417.23auopyc-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211211917.ylicunmb-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211212249.livtpi3y-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211220547.7jd7qbi7-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

arch/arm/mach-s3c/devs.c:32:10: fatal error: linux/platform_data/dma-s3c24xx.h: 
No such file or directory
drivers/clk/clk.c:1022:5: error: redefinition of 'clk_prepare'
drivers/clk/clk.c:1268:6: error: redefinition of 'clk_is_enabled_when_prepared'
drivers/clk/clk.c:941:6: error: redefinition of 'clk_unprepare'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4939: warning: This comment 
starts with '/**', but isn't a kernel-doc comment. Refer 
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5075:24: warning: 
implicit conversion from 'enum ' to 'enum dc_status' 
[-Wenum-conversion]
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:139:43:
 warning: unused variable 'dmub_outbox_irq_info_funcs' [-Wunused-const-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:40:20: 
warning: no previous prototype for 'to_dal_irq_source_dcn201' 
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:40:20: 
warning: no previous prototype for function 'to_dal_irq_source_dcn201' 
[-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous 
prototype for 'gf100_fifo_nonstall_block' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous 
prototype for function 'gf100_fifo_nonstall_block' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous 
prototype for 'nvkm_engn_cgrp_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous 
prototype for function 'nvkm_engn_cgrp_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous 
prototype for 'tu102_gr_load' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous 
prototype for function 'tu102_gr_load' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype 
for 'wpr_generic_header_dump' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype 
for function 'wpr_generic_header_dump' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:21: warning: variable 'loc' 
set but not used [-Wunused-but-set-variable]
include/linux/ftrace.h:126:16: error: implicit declaration of function 
'arch_ftrace_get_regs'; did you mean 'ftrace_get_regs'? 
[-Werror=implicit-function-declaration]
include/linux/ftrace.h:126:16: warning: returning 'int' from a function with 
return type 'struct pt_regs *' makes pointer from integer without a cast 
[-Wint-conversion]
microblaze-linux-ld: (.text+0x158): undefined reference to `drm_bridge_add'
microblaze-linux-ld: drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.o:(.rodata+0x3b4): 
undefined reference to `drm_atomic_helper_bridge_duplicate_state'
microblaze-linux-ld: drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.o:(.rodata+0x3b8): 
undefined reference to `drm_atomic_helper_bridge_destroy_state'
microblaze-linux-ld: drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.o:(.rodata+0x3c8): 
undefined reference to `drm_atomic_helper_bridge_reset'

Unverified Error/Warning (likely false positive, please contact us if 
interested):

drivers/gpu/drm/nouveau/nouveau_dp.c:237 nouveau_dp_irq() warn: variable 
dereferenced before check 'outp' (see line 232)
drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c:116 
nvkm_uoutp_mthd_infoframe() error: we previously assumed 'ior->func->hdmi' 
could be null (see line 114)
drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c:250 nvkm_uoutp_mthd_acquire() 
error: we previously assumed 'outp->ior' could be null (see line 217)
drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c:133 nvkm_chan_cctx_get() warn: 
inconsistent returns '&cgrp->mutex'.
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: 
inconsistent returns '&gr

[PATCH] drm/msm/dpu: Print interrupt index in addition to the mask

[Marijn Suijten]

The mask only describes the `irq_idx % 32` part, making it generally
impossible to deduce what interrupt is being enabled/disabled.  Since
`debug/core_irq` in debugfs (and other prints) also include the full
`DPU_IRQ_IDX()` value, print the same full value here for easier
correlation instead of only adding the `irq_idx / 32` part.

Furthermore, make the dbgstr messages more consistent.

Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 12 ++--
 1 file changed, 6 insertions(+), 6 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 cf1b6d84c18a..64589a9c2c51 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -252,9 +252,9 @@ static int dpu_hw_intr_enable_irq_locked(struct dpu_hw_intr 
*intr, int irq_idx)
 
cache_irq_mask = intr->cache_irq_mask[reg_idx];
if (cache_irq_mask & DPU_IRQ_MASK(irq_idx)) {
-   dbgstr = "DPU IRQ already set:";
+   dbgstr = "already ";
} else {
-   dbgstr = "DPU IRQ enabled:";
+   dbgstr = "";
 
cache_irq_mask |= DPU_IRQ_MASK(irq_idx);
/* Cleaning any pending interrupt */
@@ -268,7 +268,7 @@ static int dpu_hw_intr_enable_irq_locked(struct dpu_hw_intr 
*intr, int irq_idx)
intr->cache_irq_mask[reg_idx] = cache_irq_mask;
}
 
-   pr_debug("%s MASK:0x%.8lx, CACHE-MASK:0x%.8x\n", dbgstr,
+   pr_debug("DPU IRQ %d %senabled: MASK:0x%.8lx, CACHE-MASK:0x%.8x\n", 
irq_idx, dbgstr,
DPU_IRQ_MASK(irq_idx), cache_irq_mask);
 
return 0;
@@ -301,9 +301,9 @@ static int dpu_hw_intr_disable_irq_locked(struct 
dpu_hw_intr *intr, int irq_idx)
 
cache_irq_mask = intr->cache_irq_mask[reg_idx];
if ((cache_irq_mask & DPU_IRQ_MASK(irq_idx)) == 0) {
-   dbgstr = "DPU IRQ is already cleared:";
+   dbgstr = "already ";
} else {
-   dbgstr = "DPU IRQ mask disable:";
+   dbgstr = "";
 
cache_irq_mask &= ~DPU_IRQ_MASK(irq_idx);
/* Disable interrupts based on the new mask */
@@ -317,7 +317,7 @@ static int dpu_hw_intr_disable_irq_locked(struct 
dpu_hw_intr *intr, int irq_idx)
intr->cache_irq_mask[reg_idx] = cache_irq_mask;
}
 
-   pr_debug("%s MASK:0x%.8lx, CACHE-MASK:0x%.8x\n", dbgstr,
+   pr_debug("DPU IRQ %d %sdisabled: MASK:0x%.8lx, CACHE-MASK:0x%.8x\n", 
irq_idx, dbgstr,
DPU_IRQ_MASK(irq_idx), cache_irq_mask);
 
return 0;
-- 
2.38.1

[PATCH] drm/mediatek: Clean dangling pointer on bind error path

[Nícolas F . R . A . Prado]

mtk_drm_bind() can fail, in which case drm_dev_put() is called,
destroying the drm_device object. However a pointer to it was still
being held in the private object, and that pointer would be passed along
to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that
point, resulting in a panic. Clean the pointer when destroying the
object in the error path to prevent this from happening.

Signed-off-by: Nícolas F. R. A. Prado 

---

 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 39a42dc8fb85..a21ff1b3258c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev)
 err_deinit:
mtk_drm_kms_deinit(drm);
 err_free:
+   private->drm = NULL;
drm_dev_put(drm);
return ret;
 }
-- 
2.38.1

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Sonal Santan]

On 11/19/22 12:44, Oded Gabbay wrote:
> This is the fourth (and hopefully last) version of the patch-set to add the
> new subsystem for compute accelerators. I removed the RFC headline as
> I believe it is now ready for merging.
> 
> Compare to v3, this patch-set contains one additional patch that adds
> documentation regarding the accel subsystem. I hope it's good enough for
> this stage. In addition, there were few very minor fixes according to
> comments received on v3.
> 
> The patches are in the following repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
> 
> As in v3, The HEAD of that branch is a commit adding a dummy driver that
> registers an accel device using the new framework. This can be served
> as a simple reference.
> 
> v1 cover letter:
> https://lkml.org/lkml/2022/10/22/544
> 
> v2 cover letter:
> https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/
> 
> v3 cover letter:
> https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/

Thanks for defining the new accel subsystem. We are currently working on
DRM based drivers for unannounced acceleration devices. I am fine with
these changes with the assumption that the choice of using classic DRM
or accel is left up to the individual driver.

-Sonal

> 
> Thanks,
> Oded.
> 
> Oded Gabbay (4):
>   drivers/accel: define kconfig and register a new major
>   accel: add dedicated minor for accelerator devices
>   drm: initialize accel framework
>   doc: add documentation for accel subsystem
> 
>  Documentation/accel/index.rst |  17 ++
>  Documentation/accel/introduction.rst  | 109 +
>  Documentation/admin-guide/devices.txt |   5 +
>  Documentation/subsystem-apis.rst  |   1 +
>  MAINTAINERS   |   9 +
>  drivers/Kconfig   |   2 +
>  drivers/accel/Kconfig |  24 ++
>  drivers/accel/drm_accel.c | 323 ++
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/drm_drv.c | 102 +---
>  drivers/gpu/drm/drm_file.c|   2 +-
>  drivers/gpu/drm/drm_sysfs.c   |  24 +-
>  include/drm/drm_accel.h   |  97 
>  include/drm/drm_device.h  |   3 +
>  include/drm/drm_drv.h |   8 +
>  include/drm/drm_file.h|  21 +-
>  16 files changed, 711 insertions(+), 37 deletions(-)
>  create mode 100644 Documentation/accel/index.rst
>  create mode 100644 Documentation/accel/introduction.rst
>  create mode 100644 drivers/accel/Kconfig
>  create mode 100644 drivers/accel/drm_accel.c
>  create mode 100644 include/drm/drm_accel.h
> 
> --
> 2.25.1
> 

[PATCH 0/6] drm/i915: Add support for GSC FW loading

[Daniele Ceraolo Spurio]

Starting from MTL, the GSC FW is runtime loaded by the driver, instead
of being stored in flash memory. Loading the GSC FW is required to allow
the media GT to go into its C6 state and for content protection features
(PXP, HDCP).

The loading happens via a submission to the GSC engine. All subsequent
communication with the FW will also happen via the engine, although no
further messages are implemented as part of this series. The loading is
currently done serially as part of driver init/resume, but the plan is
to move it to a worker thread in the future to allow non-CP submission
to go through while we wait for GSC FW load to complete. This will be
done once all the pieces required for GSC to fully function are in place
(see further below).

This series also adds the GSC engine flag to the MTL platform, with the
engine being runtime disabled if the FW is not selected, which makes the
FW definition (not included in the series) the ultimate enabler for the
whole GSC block.

Note that just loading the FW is not enough for it to be fully
functional. We'll also need to establish and handle a communication
channel between GSC and CSME (a.k.a. SW proxy). This will require a new
mei component to handle the CSME side of things, so it will be pushed as
a separate series.

Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 

Daniele Ceraolo Spurio (5):
  drm/i915/uc: Introduce GSC FW
  drm/i915/gsc: Skip the version check when fetching the GSC FW
  drm/i915/gsc: GSC firmware loading
  drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
  drm/i915/mtl: MTL has one GSC CS on the media GT

Jonathan Cavitt (1):
  drm/i915/gsc: Disable GSC engine and power well if FW is not selected

 drivers/gpu/drm/i915/Makefile|   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  14 +-
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c|  18 ++
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/intel_gt.c   |  11 ++
 drivers/gpu/drm/i915/gt/intel_gt.h   |   5 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 195 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  13 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c| 103 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  43 
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|  32 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h|   5 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  74 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   8 +-
 drivers/gpu/drm/i915/i915_params.c   |   3 +
 drivers/gpu/drm/i915/i915_params.h   |   1 +
 drivers/gpu/drm/i915/i915_pci.c  |   2 +-
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_uncore.c  |  48 +
 drivers/gpu/drm/i915/intel_uncore.h  |  13 ++
 21 files changed, 585 insertions(+), 19 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

-- 
2.37.3