[PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Biju Das]

Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
---
 Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
index 9dff7e5..29159f4 100644
--- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
+++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
@@ -11,6 +11,7 @@ Required Properties:
   - compatible: must contain one or more of the following:
     - "renesas,tmu-r8a7740" for the r8a7740 TMU
     - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
+    - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
     - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
     - "renesas,tmu-r8a7778" for the r8a7778 TMU
     - "renesas,tmu-r8a7779" for the r8a7779 TMU
-- 
2.7.4

[PATCH v1 0/2] Free the writeback_job when it with an empty fb

[Lowry Li (Arm Technology China)]

Hi,

This serie aims at adding the check and free the writeback_job when it
with an empty fb in drm_atomic_connector_check().

Also did some refine in drm_writeback_signal_completion() to clear the
fence pointer when writeback job signaled.

This patchset is based at the drm-misc-fixes branch.

Lowry Li (Arm Technology China) (2):
  drm: Free the writeback_job when it with an empty fb
  drm: Clear the fence pointer when writeback job signaled

 .../drm/arm/display/komeda/komeda_wb_connector.c   |  3 +--
 drivers/gpu/drm/arm/malidp_mw.c                    |  4 ++--
 drivers/gpu/drm/drm_atomic.c                       | 13 ++++++++----
 drivers/gpu/drm/drm_writeback.c                    | 23 ++++++++++++++--------
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c        |  4 ++--
 drivers/gpu/drm/vc4/vc4_txp.c                      |  5 ++---
 6 files changed, 31 insertions(+), 21 deletions(-)

-- 
1.9.1

[PATCH v1 1/2] drm: Free the writeback_job when it with an empty fb

[Lowry Li (Arm Technology China)]

From: "Lowry Li (Arm Technology China)" <Lowry.Li@arm.com>

Adds the check if the writeback_job with an empty fb, then it should
be freed in atomic_check phase.

With this change, the driver users will not check empty fb case any more.
So refined accordingly.

Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
---
 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c |  3 +--
 drivers/gpu/drm/arm/malidp_mw.c                          |  4 ++--
 drivers/gpu/drm/drm_atomic.c                             | 13 +++++++++----
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c              |  4 ++--
 drivers/gpu/drm/vc4/vc4_txp.c                            |  5 ++---
 5 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index 617e1f7..d6103dd 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -43,9 +43,8 @@
 	struct komeda_data_flow_cfg dflow;
 	int err;
 
-	if (!writeback_job || !writeback_job->fb) {
+	if (!writeback_job)
 		return 0;
-	}
 
 	if (!crtc_st->active) {
 		DRM_DEBUG_ATOMIC("Cannot write the composition result out on a inactive CRTC.\n");
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 2e81252..a59227b 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -130,7 +130,7 @@ static void malidp_mw_connector_destroy(struct drm_connector *connector)
 	struct drm_framebuffer *fb;
 	int i, n_planes;
 
-	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
+	if (!conn_state->writeback_job)
 		return 0;
 
 	fb = conn_state->writeback_job->fb;
@@ -247,7 +247,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
 
 	mw_state = to_mw_state(conn_state);
 
-	if (conn_state->writeback_job && conn_state->writeback_job->fb) {
+	if (conn_state->writeback_job) {
 		struct drm_framebuffer *fb = conn_state->writeback_job->fb;
 
 		DRM_DEV_DEBUG_DRIVER(drm->dev,
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 419381a..14aeaf7 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -430,10 +430,15 @@ static int drm_atomic_connector_check(struct drm_connector *connector,
 		return -EINVAL;
 	}
 
-	if (writeback_job->out_fence && !writeback_job->fb) {
-		DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence without framebuffer\n",
-				 connector->base.id, connector->name);
-		return -EINVAL;
+	if (!writeback_job->fb) {
+		if (writeback_job->out_fence) {
+			DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence without framebuffer\n",
+					 connector->base.id, connector->name);
+			return -EINVAL;
+		}
+
+		drm_writeback_cleanup_job(writeback_job);
+		state->writeback_job = NULL;
 	}
 
 	return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
index ae07290..04efa78d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
@@ -147,7 +147,7 @@ static int rcar_du_wb_enc_atomic_check(struct drm_encoder *encoder,
 	struct drm_device *dev = encoder->dev;
 	struct drm_framebuffer *fb;
 
-	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
+	if (!conn_state->writeback_job)
 		return 0;
 
 	fb = conn_state->writeback_job->fb;
@@ -221,7 +221,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
 	unsigned int i;
 
 	state = rcrtc->writeback.base.state;
-	if (!state || !state->writeback_job || !state->writeback_job->fb)
+	if (!state || !state->writeback_job)
 		return;
 
 	fb = state->writeback_job->fb;
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 96f91c1..e92fa12 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -229,7 +229,7 @@ static int vc4_txp_connector_atomic_check(struct drm_connector *conn,
 	int i;
 
 	conn_state = drm_atomic_get_new_connector_state(state, conn);
-	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
+	if (!conn_state->writeback_job)
 		return 0;
 
 	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
@@ -269,8 +269,7 @@ static void vc4_txp_connector_atomic_commit(struct drm_connector *conn,
 	u32 ctrl;
 	int i;
 
-	if (WARN_ON(!conn_state->writeback_job ||
-		    !conn_state->writeback_job->fb))
+	if (WARN_ON(!conn_state->writeback_job))
 		return;
 
 	mode = &conn_state->crtc->state->adjusted_mode;
-- 
1.9.1

Re: [PATCH v1 1/2] drm: Free the writeback_job when it with an empty fb

[Liviu Dudau]

On Wed, Jul 31, 2019 at 11:04:38AM +0000, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)" <Lowry.Li@arm.com>
> 
> Adds the check if the writeback_job with an empty fb, then it should
> be freed in atomic_check phase.
> 
> With this change, the driver users will not check empty fb case any more.
> So refined accordingly.
> 
> Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>

Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c |  3 +--
>  drivers/gpu/drm/arm/malidp_mw.c                          |  4 ++--
>  drivers/gpu/drm/drm_atomic.c                             | 13 +++++++++----
>  drivers/gpu/drm/rcar-du/rcar_du_writeback.c              |  4 ++--
>  drivers/gpu/drm/vc4/vc4_txp.c                            |  5 ++---
>  5 files changed, 16 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> index 617e1f7..d6103dd 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> @@ -43,9 +43,8 @@
>  	struct komeda_data_flow_cfg dflow;
>  	int err;
>  
> -	if (!writeback_job || !writeback_job->fb) {
> +	if (!writeback_job)
>  		return 0;
> -	}
>  
>  	if (!crtc_st->active) {
>  		DRM_DEBUG_ATOMIC("Cannot write the composition result out on a inactive CRTC.\n");
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 2e81252..a59227b 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -130,7 +130,7 @@ static void malidp_mw_connector_destroy(struct drm_connector *connector)
>  	struct drm_framebuffer *fb;
>  	int i, n_planes;
>  
> -	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> +	if (!conn_state->writeback_job)
>  		return 0;
>  
>  	fb = conn_state->writeback_job->fb;
> @@ -247,7 +247,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
>  
>  	mw_state = to_mw_state(conn_state);
>  
> -	if (conn_state->writeback_job && conn_state->writeback_job->fb) {
> +	if (conn_state->writeback_job) {
>  		struct drm_framebuffer *fb = conn_state->writeback_job->fb;
>  
>  		DRM_DEV_DEBUG_DRIVER(drm->dev,
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 419381a..14aeaf7 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -430,10 +430,15 @@ static int drm_atomic_connector_check(struct drm_connector *connector,
>  		return -EINVAL;
>  	}
>  
> -	if (writeback_job->out_fence && !writeback_job->fb) {
> -		DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence without framebuffer\n",
> -				 connector->base.id, connector->name);
> -		return -EINVAL;
> +	if (!writeback_job->fb) {
> +		if (writeback_job->out_fence) {
> +			DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence without framebuffer\n",
> +					 connector->base.id, connector->name);
> +			return -EINVAL;
> +		}
> +
> +		drm_writeback_cleanup_job(writeback_job);
> +		state->writeback_job = NULL;
>  	}
>  
>  	return 0;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> index ae07290..04efa78d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> @@ -147,7 +147,7 @@ static int rcar_du_wb_enc_atomic_check(struct drm_encoder *encoder,
>  	struct drm_device *dev = encoder->dev;
>  	struct drm_framebuffer *fb;
>  
> -	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> +	if (!conn_state->writeback_job)
>  		return 0;
>  
>  	fb = conn_state->writeback_job->fb;
> @@ -221,7 +221,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
>  	unsigned int i;
>  
>  	state = rcrtc->writeback.base.state;
> -	if (!state || !state->writeback_job || !state->writeback_job->fb)
> +	if (!state || !state->writeback_job)
>  		return;
>  
>  	fb = state->writeback_job->fb;
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index 96f91c1..e92fa12 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -229,7 +229,7 @@ static int vc4_txp_connector_atomic_check(struct drm_connector *conn,
>  	int i;
>  
>  	conn_state = drm_atomic_get_new_connector_state(state, conn);
> -	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> +	if (!conn_state->writeback_job)
>  		return 0;
>  
>  	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> @@ -269,8 +269,7 @@ static void vc4_txp_connector_atomic_commit(struct drm_connector *conn,
>  	u32 ctrl;
>  	int i;
>  
> -	if (WARN_ON(!conn_state->writeback_job ||
> -		    !conn_state->writeback_job->fb))
> +	if (WARN_ON(!conn_state->writeback_job))
>  		return;
>  
>  	mode = &conn_state->crtc->state->adjusted_mode;
> -- 
> 1.9.1
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [v1,1/2] drm: Free the writeback_job when it with an empty fb

[james qian wang (Arm Technology China)]

On Wed, Jul 31, 2019 at 11:04:38AM +0000, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)" <Lowry.Li@arm.com>
> 
> Adds the check if the writeback_job with an empty fb, then it should
> be freed in atomic_check phase.
> 
> With this change, the driver users will not check empty fb case any more.
> So refined accordingly.
> 
> Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>

Looks good to me.

Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>

And will push it to drm-misc-fixes

James

> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c |  3 +--
>  drivers/gpu/drm/arm/malidp_mw.c                          |  4 ++--
>  drivers/gpu/drm/drm_atomic.c                             | 13 +++++++++----
>  drivers/gpu/drm/rcar-du/rcar_du_writeback.c              |  4 ++--
>  drivers/gpu/drm/vc4/vc4_txp.c                            |  5 ++---
>  5 files changed, 16 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> index 617e1f7..d6103dd 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
> @@ -43,9 +43,8 @@
>  	struct komeda_data_flow_cfg dflow;
>  	int err;
>  
> -	if (!writeback_job || !writeback_job->fb) {
> +	if (!writeback_job)
>  		return 0;
> -	}
>  
>  	if (!crtc_st->active) {
>  		DRM_DEBUG_ATOMIC("Cannot write the composition result out on a inactive CRTC.\n");
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 2e81252..a59227b 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -130,7 +130,7 @@ static void malidp_mw_connector_destroy(struct drm_connector *connector)
>  	struct drm_framebuffer *fb;
>  	int i, n_planes;
>  
> -	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> +	if (!conn_state->writeback_job)
>  		return 0;
>  
>  	fb = conn_state->writeback_job->fb;
> @@ -247,7 +247,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
>  
>  	mw_state = to_mw_state(conn_state);
>  
> -	if (conn_state->writeback_job && conn_state->writeback_job->fb) {
> +	if (conn_state->writeback_job) {
>  		struct drm_framebuffer *fb = conn_state->writeback_job->fb;
>  
>  		DRM_DEV_DEBUG_DRIVER(drm->dev,
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 419381a..14aeaf7 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -430,10 +430,15 @@ static int drm_atomic_connector_check(struct drm_connector *connector,
>  		return -EINVAL;
>  	}
>  
> -	if (writeback_job->out_fence && !writeback_job->fb) {
> -		DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence without framebuffer\n",
> -				 connector->base.id, connector->name);
> -		return -EINVAL;
> +	if (!writeback_job->fb) {
> +		if (writeback_job->out_fence) {
> +			DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] requesting out-fence without framebuffer\n",
> +					 connector->base.id, connector->name);
> +			return -EINVAL;
> +		}
> +
> +		drm_writeback_cleanup_job(writeback_job);
> +		state->writeback_job = NULL;
>  	}
>  
>  	return 0;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> index ae07290..04efa78d 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
> @@ -147,7 +147,7 @@ static int rcar_du_wb_enc_atomic_check(struct drm_encoder *encoder,
>  	struct drm_device *dev = encoder->dev;
>  	struct drm_framebuffer *fb;
>  
> -	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> +	if (!conn_state->writeback_job)
>  		return 0;
>  
>  	fb = conn_state->writeback_job->fb;
> @@ -221,7 +221,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
>  	unsigned int i;
>  
>  	state = rcrtc->writeback.base.state;
> -	if (!state || !state->writeback_job || !state->writeback_job->fb)
> +	if (!state || !state->writeback_job)
>  		return;
>  
>  	fb = state->writeback_job->fb;
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index 96f91c1..e92fa12 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -229,7 +229,7 @@ static int vc4_txp_connector_atomic_check(struct drm_connector *conn,
>  	int i;
>  
>  	conn_state = drm_atomic_get_new_connector_state(state, conn);
> -	if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> +	if (!conn_state->writeback_job)
>  		return 0;
>  
>  	crtc_state = drm_atomic_get_new_crtc_state(state, conn_state->crtc);
> @@ -269,8 +269,7 @@ static void vc4_txp_connector_atomic_commit(struct drm_connector *conn,
>  	u32 ctrl;
>  	int i;
>  
> -	if (WARN_ON(!conn_state->writeback_job ||
> -		    !conn_state->writeback_job->fb))
> +	if (WARN_ON(!conn_state->writeback_job))
>  		return;
>  
>  	mode = &conn_state->crtc->state->adjusted_mode;

[PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Lowry Li (Arm Technology China)]

During it signals the completion of a writeback job, after releasing
the out_fence, we'd clear the pointer.

Check if fence left over in drm_writeback_cleanup_job(), release it.

Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
---
 drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index ff138b6..43d9e3b 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
 	if (job->fb)
 		drm_framebuffer_put(job->fb);
 
+	if (job->out_fence)
+		dma_fence_put(job->out_fence);
+
 	kfree(job);
 }
 EXPORT_SYMBOL(drm_writeback_cleanup_job);
@@ -366,25 +369,29 @@ static void cleanup_work(struct work_struct *work)
 {
 	unsigned long flags;
 	struct drm_writeback_job *job;
+	struct dma_fence *out_fence;
 
 	spin_lock_irqsave(&wb_connector->job_lock, flags);
 	job = list_first_entry_or_null(&wb_connector->job_queue,
 				       struct drm_writeback_job,
 				       list_entry);
-	if (job) {
+	if (job)
 		list_del(&job->list_entry);
-		if (job->out_fence) {
-			if (status)
-				dma_fence_set_error(job->out_fence, status);
-			dma_fence_signal(job->out_fence);
-			dma_fence_put(job->out_fence);
-		}
-	}
+
 	spin_unlock_irqrestore(&wb_connector->job_lock, flags);
 
 	if (WARN_ON(!job))
 		return;
 
+	out_fence = job->out_fence;
+	if (out_fence) {
+		if (status)
+			dma_fence_set_error(out_fence, status);
+		dma_fence_signal(out_fence);
+		dma_fence_put(out_fence);
+		job->out_fence = NULL;
+	}
+
 	INIT_WORK(&job->cleanup_work, cleanup_work);
 	queue_work(system_long_wq, &job->cleanup_work);
 }
-- 
1.9.1

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Liviu Dudau]

Hi Lowry,

On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> During it signals the completion of a writeback job, after releasing
> the out_fence, we'd clear the pointer.
> 
> Check if fence left over in drm_writeback_cleanup_job(), release it.
> 
> Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> ---
>  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index ff138b6..43d9e3b 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
>  	if (job->fb)
>  		drm_framebuffer_put(job->fb);
>  
> +	if (job->out_fence)
> +		dma_fence_put(job->out_fence);
> +
>  	kfree(job);
>  }

This change looks good.

>  EXPORT_SYMBOL(drm_writeback_cleanup_job);
> @@ -366,25 +369,29 @@ static void cleanup_work(struct work_struct *work)
>  {
>  	unsigned long flags;
>  	struct drm_writeback_job *job;
> +	struct dma_fence *out_fence;
>  
>  	spin_lock_irqsave(&wb_connector->job_lock, flags);
>  	job = list_first_entry_or_null(&wb_connector->job_queue,
>  				       struct drm_writeback_job,
>  				       list_entry);
> -	if (job) {
> +	if (job)
>  		list_del(&job->list_entry);
> -		if (job->out_fence) {
> -			if (status)
> -				dma_fence_set_error(job->out_fence, status);
> -			dma_fence_signal(job->out_fence);
> -			dma_fence_put(job->out_fence);

*Here*

> -		}
> -	}
> +
>  	spin_unlock_irqrestore(&wb_connector->job_lock, flags);
>  
>  	if (WARN_ON(!job))
>  		return;
>  
> +	out_fence = job->out_fence;
> +	if (out_fence) {
> +		if (status)
> +			dma_fence_set_error(out_fence, status);
> +		dma_fence_signal(out_fence);
> +		dma_fence_put(out_fence);
> +		job->out_fence = NULL;
> +	}
> +

I don't get the point of this change. Why not just add job->out_fence = NULL
where *Here* is?

Best regards,
Liviu 

>  	INIT_WORK(&job->cleanup_work, cleanup_work);
>  	queue_work(system_long_wq, &job->cleanup_work);
>  }
> -- 
> 1.9.1
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Liviu Dudau]

On Thu, Aug 01, 2019 at 06:31:13AM +0000, Lowry Li (Arm Technology China) wrote:
> Hi Liviu,
> 
> On Wed, Jul 31, 2019 at 01:15:25PM +0000, Liviu Dudau wrote:
> > Hi Lowry,
> > 
> > On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> > > During it signals the completion of a writeback job, after releasing
> > > the out_fence, we'd clear the pointer.
> > > 
> > > Check if fence left over in drm_writeback_cleanup_job(), release it.
> > > 
> > > Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> > > ---
> > >  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
> > >  1 file changed, 15 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> > > index ff138b6..43d9e3b 100644
> > > --- a/drivers/gpu/drm/drm_writeback.c
> > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> > >  	if (job->fb)
> > >  		drm_framebuffer_put(job->fb);
> > >  
> > > +	if (job->out_fence)
> > > +		dma_fence_put(job->out_fence);
> > > +
> > >  	kfree(job);
> > >  }
> > 
> > This change looks good.
> > 
> > >  EXPORT_SYMBOL(drm_writeback_cleanup_job);
> > > @@ -366,25 +369,29 @@ static void cleanup_work(struct work_struct *work)
> > >  {
> > >  	unsigned long flags;
> > >  	struct drm_writeback_job *job;
> > > +	struct dma_fence *out_fence;
> > >  
> > >  	spin_lock_irqsave(&wb_connector->job_lock, flags);
> > >  	job = list_first_entry_or_null(&wb_connector->job_queue,
> > >  				       struct drm_writeback_job,
> > >  				       list_entry);
> > > -	if (job) {
> > > +	if (job)
> > >  		list_del(&job->list_entry);
> > > -		if (job->out_fence) {
> > > -			if (status)
> > > -				dma_fence_set_error(job->out_fence, status);
> > > -			dma_fence_signal(job->out_fence);
> > > -			dma_fence_put(job->out_fence);
> > 
> > *Here*
> > 
> > > -		}
> > > -	}
> > > +
> > >  	spin_unlock_irqrestore(&wb_connector->job_lock, flags);
> > >  
> > >  	if (WARN_ON(!job))
> > >  		return;
> > >  
> > > +	out_fence = job->out_fence;
> > > +	if (out_fence) {
> > > +		if (status)
> > > +			dma_fence_set_error(out_fence, status);
> > > +		dma_fence_signal(out_fence);
> > > +		dma_fence_put(out_fence);
> > > +		job->out_fence = NULL;
> > > +	}
> > > +
> > 
> > I don't get the point of this change. Why not just add job->out_fence = NULL
> > where *Here* is?
> >
> > Best regards,
> > Liviu 
> Besides setting NULL, also did a refine by moving the fence operation
> out of the lock block.

OK, now it makes sense. May I suggest you add that to the commit message?

Otherwise, Acked-by: Liviu Dudau <liviu.dudau@arm.com>

Best regards,
Liviu

> 
> Best regards,
> Lowry 
> > >  	INIT_WORK(&job->cleanup_work, cleanup_work);
> > >  	queue_work(system_long_wq, &job->cleanup_work);
> > >  }
> > > -- 
> > > 1.9.1
> > > 
> > 
> > -- 
> > ====================
> > | I would like to |
> > | fix the world,  |
> > | but they're not |
> > | giving me the   |
> >  \ source code!  /
> >   ---------------
> >     ¯\_(ツ)_/¯
> 
> -- 
> Regards,
> Lowry

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Brian Starkey]

Hi Lowry,

Thanks for this cleanup.

On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> During it signals the completion of a writeback job, after releasing
> the out_fence, we'd clear the pointer.
> 
> Check if fence left over in drm_writeback_cleanup_job(), release it.
> 
> Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> ---
>  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index ff138b6..43d9e3b 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
>  	if (job->fb)
>  		drm_framebuffer_put(job->fb);
>  
> +	if (job->out_fence)

I'm thinking it might be a good idea to signal the fence with an error
here, if it's not already signaled. Otherwise, if there's someone
waiting (which there shouldn't be), they're going to be waiting a very
long time :-)

Thanks,
-Brian

> +		dma_fence_put(job->out_fence);
> +
>  	kfree(job);
>  }

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Brian Starkey]

Hi Lowry,

On Thu, Aug 01, 2019 at 06:34:08AM +0000, Lowry Li (Arm Technology China) wrote:
> Hi Brian,
> 
> On Wed, Jul 31, 2019 at 09:20:04PM +0800, Brian Starkey wrote:
> > Hi Lowry,
> > 
> > Thanks for this cleanup.
> > 
> > On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> > > During it signals the completion of a writeback job, after releasing
> > > the out_fence, we'd clear the pointer.
> > > 
> > > Check if fence left over in drm_writeback_cleanup_job(), release it.
> > > 
> > > Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> > > ---
> > >  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
> > >  1 file changed, 15 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> > > index ff138b6..43d9e3b 100644
> > > --- a/drivers/gpu/drm/drm_writeback.c
> > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> > >  	if (job->fb)
> > >  		drm_framebuffer_put(job->fb);
> > >  
> > > +	if (job->out_fence)
> > 
> > I'm thinking it might be a good idea to signal the fence with an error
> > here, if it's not already signaled. Otherwise, if there's someone
> > waiting (which there shouldn't be), they're going to be waiting a very
> > long time :-)
> > 
> > Thanks,
> > -Brian
> > 
> Here it happened at atomic_check failed and test only commit. For both
> cases, the commit has been dropped and it's only a clean up. So here better
> not be treated as an error case:)

If anyone else has a reference on the fence, then IMO it absolutely is
an error to reach this point without the fence being signaled -
because it means that the fence will never be signaled.

I don't think the API gives you a way to check if this is the last
reference, so it's safest to just make sure the fence is signalled
before dropping the reference.

It just feels wrong to me to have the possibility of a dangling fence
which is never going to get signalled; and it's an easy defensive step
to make sure it can never happen.

I know it _shouldn't_ happen, but we often put in handling for cases
which shouldn't happen, because they frequently do happen :-)

> 
> Since for userspace, it should have been failed or a test only case, so
> writebace fence should not be signaled.

It's not only userspace that can wait on fences (and in fact this
fence will never even reach userspace if the commit fails), the driver
may have taken a copy to use for "something".

Cheers,
-Brian

> 
> Best regards,
> Lowry
> > > +		dma_fence_put(job->out_fence);
> > > +
> > >  	kfree(job);
> > >  }
> 
> -- 
> Regards,
> Lowry

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Daniel Vetter]

On Fri, Aug 2, 2019 at 11:29 AM Brian Starkey <Brian.Starkey@arm.com> wrote:
>
> Hi Lowry,
>
> On Thu, Aug 01, 2019 at 06:34:08AM +0000, Lowry Li (Arm Technology China) wrote:
> > Hi Brian,
> >
> > On Wed, Jul 31, 2019 at 09:20:04PM +0800, Brian Starkey wrote:
> > > Hi Lowry,
> > >
> > > Thanks for this cleanup.
> > >
> > > On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> > > > During it signals the completion of a writeback job, after releasing
> > > > the out_fence, we'd clear the pointer.
> > > >
> > > > Check if fence left over in drm_writeback_cleanup_job(), release it.
> > > >
> > > > Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> > > > ---
> > > >  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
> > > >  1 file changed, 15 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> > > > index ff138b6..43d9e3b 100644
> > > > --- a/drivers/gpu/drm/drm_writeback.c
> > > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > > @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> > > >   if (job->fb)
> > > >           drm_framebuffer_put(job->fb);
> > > >
> > > > + if (job->out_fence)
> > >
> > > I'm thinking it might be a good idea to signal the fence with an error
> > > here, if it's not already signaled. Otherwise, if there's someone
> > > waiting (which there shouldn't be), they're going to be waiting a very
> > > long time :-)
> > >
> > > Thanks,
> > > -Brian
> > >
> > Here it happened at atomic_check failed and test only commit. For both
> > cases, the commit has been dropped and it's only a clean up. So here better
> > not be treated as an error case:)
>
> If anyone else has a reference on the fence, then IMO it absolutely is
> an error to reach this point without the fence being signaled -
> because it means that the fence will never be signaled.
>
> I don't think the API gives you a way to check if this is the last
> reference, so it's safest to just make sure the fence is signalled
> before dropping the reference.
>
> It just feels wrong to me to have the possibility of a dangling fence
> which is never going to get signalled; and it's an easy defensive step
> to make sure it can never happen.
>
> I know it _shouldn't_ happen, but we often put in handling for cases
> which shouldn't happen, because they frequently do happen :-)

We're not as paranoid with the vblank fences either, so not sure why
we need to be this paranoid with writeback fences. If your driver
grabs anything from the atomic state in ->atomic_check it's buggy
anyway.

If you want to fix this properly I think we need to move the call to
prepare_signalling() in between atomic_check and atomic_commit. Then I
think it makes sense to also force-complete the fence on error ...
-Daniel

> > Since for userspace, it should have been failed or a test only case, so
> > writebace fence should not be signaled.
>
> It's not only userspace that can wait on fences (and in fact this
> fence will never even reach userspace if the commit fails), the driver
> may have taken a copy to use for "something".
>
> Cheers,
> -Brian
>
> >
> > Best regards,
> > Lowry
> > > > +         dma_fence_put(job->out_fence);
> > > > +
> > > >   kfree(job);
> > > >  }
> >
> > --
> > Regards,
> > Lowry



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Daniel Vetter]

On Fri, Aug 2, 2019 at 11:43 AM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Fri, Aug 2, 2019 at 11:29 AM Brian Starkey <Brian.Starkey@arm.com> wrote:
> >
> > Hi Lowry,
> >
> > On Thu, Aug 01, 2019 at 06:34:08AM +0000, Lowry Li (Arm Technology China) wrote:
> > > Hi Brian,
> > >
> > > On Wed, Jul 31, 2019 at 09:20:04PM +0800, Brian Starkey wrote:
> > > > Hi Lowry,
> > > >
> > > > Thanks for this cleanup.
> > > >
> > > > On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> > > > > During it signals the completion of a writeback job, after releasing
> > > > > the out_fence, we'd clear the pointer.
> > > > >
> > > > > Check if fence left over in drm_writeback_cleanup_job(), release it.
> > > > >
> > > > > Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> > > > > ---
> > > > >  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
> > > > >  1 file changed, 15 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> > > > > index ff138b6..43d9e3b 100644
> > > > > --- a/drivers/gpu/drm/drm_writeback.c
> > > > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > > > @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> > > > >   if (job->fb)
> > > > >           drm_framebuffer_put(job->fb);
> > > > >
> > > > > + if (job->out_fence)
> > > >
> > > > I'm thinking it might be a good idea to signal the fence with an error
> > > > here, if it's not already signaled. Otherwise, if there's someone
> > > > waiting (which there shouldn't be), they're going to be waiting a very
> > > > long time :-)
> > > >
> > > > Thanks,
> > > > -Brian
> > > >
> > > Here it happened at atomic_check failed and test only commit. For both
> > > cases, the commit has been dropped and it's only a clean up. So here better
> > > not be treated as an error case:)
> >
> > If anyone else has a reference on the fence, then IMO it absolutely is
> > an error to reach this point without the fence being signaled -
> > because it means that the fence will never be signaled.
> >
> > I don't think the API gives you a way to check if this is the last
> > reference, so it's safest to just make sure the fence is signalled
> > before dropping the reference.
> >
> > It just feels wrong to me to have the possibility of a dangling fence
> > which is never going to get signalled; and it's an easy defensive step
> > to make sure it can never happen.
> >
> > I know it _shouldn't_ happen, but we often put in handling for cases
> > which shouldn't happen, because they frequently do happen :-)
>
> We're not as paranoid with the vblank fences either, so not sure why
> we need to be this paranoid with writeback fences. If your driver
> grabs anything from the atomic state in ->atomic_check it's buggy
> anyway.
>
> If you want to fix this properly I think we need to move the call to
> prepare_signalling() in between atomic_check and atomic_commit. Then I
> think it makes sense to also force-complete the fence on error ...
>
> > > Since for userspace, it should have been failed or a test only case, so
> > > writebace fence should not be signaled.
> >
> > It's not only userspace that can wait on fences (and in fact this
> > fence will never even reach userspace if the commit fails), the driver
> > may have taken a copy to use for "something".

I forgot to add: you can check this by looking at the fence reference
count. A WARN_ON if that's more than 1 on cleanup (but also for the
out fences) could be a nice addition.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Brian Starkey]

Hi Daniel,

On Fri, Aug 02, 2019 at 11:45:13AM +0200, Daniel Vetter wrote:
> On Fri, Aug 2, 2019 at 11:43 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Fri, Aug 2, 2019 at 11:29 AM Brian Starkey <Brian.Starkey@arm.com> wrote:
> > >
> > > Hi Lowry,
> > >
> > > On Thu, Aug 01, 2019 at 06:34:08AM +0000, Lowry Li (Arm Technology China) wrote:
> > > > Hi Brian,
> > > >
> > > > On Wed, Jul 31, 2019 at 09:20:04PM +0800, Brian Starkey wrote:
> > > > > Hi Lowry,
> > > > >
> > > > > Thanks for this cleanup.
> > > > >
> > > > > On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> > > > > > During it signals the completion of a writeback job, after releasing
> > > > > > the out_fence, we'd clear the pointer.
> > > > > >
> > > > > > Check if fence left over in drm_writeback_cleanup_job(), release it.
> > > > > >
> > > > > > Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> > > > > > ---
> > > > > >  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
> > > > > >  1 file changed, 15 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> > > > > > index ff138b6..43d9e3b 100644
> > > > > > --- a/drivers/gpu/drm/drm_writeback.c
> > > > > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > > > > @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> > > > > >   if (job->fb)
> > > > > >           drm_framebuffer_put(job->fb);
> > > > > >
> > > > > > + if (job->out_fence)
> > > > >
> > > > > I'm thinking it might be a good idea to signal the fence with an error
> > > > > here, if it's not already signaled. Otherwise, if there's someone
> > > > > waiting (which there shouldn't be), they're going to be waiting a very
> > > > > long time :-)
> > > > >
> > > > > Thanks,
> > > > > -Brian
> > > > >
> > > > Here it happened at atomic_check failed and test only commit. For both
> > > > cases, the commit has been dropped and it's only a clean up. So here better
> > > > not be treated as an error case:)
> > >
> > > If anyone else has a reference on the fence, then IMO it absolutely is
> > > an error to reach this point without the fence being signaled -
> > > because it means that the fence will never be signaled.
> > >
> > > I don't think the API gives you a way to check if this is the last
> > > reference, so it's safest to just make sure the fence is signalled
> > > before dropping the reference.
> > >
> > > It just feels wrong to me to have the possibility of a dangling fence
> > > which is never going to get signalled; and it's an easy defensive step
> > > to make sure it can never happen.
> > >
> > > I know it _shouldn't_ happen, but we often put in handling for cases
> > > which shouldn't happen, because they frequently do happen :-)
> >
> > We're not as paranoid with the vblank fences either, so not sure why
> > we need to be this paranoid with writeback fences. If your driver
> > grabs anything from the atomic state in ->atomic_check it's buggy
> > anyway.
> >
> > If you want to fix this properly I think we need to move the call to
> > prepare_signalling() in between atomic_check and atomic_commit. Then I
> > think it makes sense to also force-complete the fence on error ...

Well, fair enough. I'm struggling with "that's too paranoid" vs "fix
it properly" though? Is it a "problem" worth fixing or not?

It seems natural to me to do the fence cleanup in the cleanup function
for the object which owns the fence.

> >
> > > > Since for userspace, it should have been failed or a test only case, so
> > > > writebace fence should not be signaled.
> > >
> > > It's not only userspace that can wait on fences (and in fact this
> > > fence will never even reach userspace if the commit fails), the driver
> > > may have taken a copy to use for "something".
> 
> I forgot to add: you can check this by looking at the fence reference
> count. A WARN_ON if that's more than 1 on cleanup (but also for the
> out fences) could be a nice addition.

Do we really want to be looking at the fence internals directly like
that?

Cheers,
-Brian

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Daniel Vetter]

On Fri, Aug 02, 2019 at 10:09:05AM +0000, Brian Starkey wrote:
> Hi Daniel,
> 
> On Fri, Aug 02, 2019 at 11:45:13AM +0200, Daniel Vetter wrote:
> > On Fri, Aug 2, 2019 at 11:43 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Fri, Aug 2, 2019 at 11:29 AM Brian Starkey <Brian.Starkey@arm.com> wrote:
> > > >
> > > > Hi Lowry,
> > > >
> > > > On Thu, Aug 01, 2019 at 06:34:08AM +0000, Lowry Li (Arm Technology China) wrote:
> > > > > Hi Brian,
> > > > >
> > > > > On Wed, Jul 31, 2019 at 09:20:04PM +0800, Brian Starkey wrote:
> > > > > > Hi Lowry,
> > > > > >
> > > > > > Thanks for this cleanup.
> > > > > >
> > > > > > On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> > > > > > > During it signals the completion of a writeback job, after releasing
> > > > > > > the out_fence, we'd clear the pointer.
> > > > > > >
> > > > > > > Check if fence left over in drm_writeback_cleanup_job(), release it.
> > > > > > >
> > > > > > > Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
> > > > > > >  1 file changed, 15 insertions(+), 8 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> > > > > > > index ff138b6..43d9e3b 100644
> > > > > > > --- a/drivers/gpu/drm/drm_writeback.c
> > > > > > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > > > > > @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> > > > > > >   if (job->fb)
> > > > > > >           drm_framebuffer_put(job->fb);
> > > > > > >
> > > > > > > + if (job->out_fence)
> > > > > >
> > > > > > I'm thinking it might be a good idea to signal the fence with an error
> > > > > > here, if it's not already signaled. Otherwise, if there's someone
> > > > > > waiting (which there shouldn't be), they're going to be waiting a very
> > > > > > long time :-)
> > > > > >
> > > > > > Thanks,
> > > > > > -Brian
> > > > > >
> > > > > Here it happened at atomic_check failed and test only commit. For both
> > > > > cases, the commit has been dropped and it's only a clean up. So here better
> > > > > not be treated as an error case:)
> > > >
> > > > If anyone else has a reference on the fence, then IMO it absolutely is
> > > > an error to reach this point without the fence being signaled -
> > > > because it means that the fence will never be signaled.
> > > >
> > > > I don't think the API gives you a way to check if this is the last
> > > > reference, so it's safest to just make sure the fence is signalled
> > > > before dropping the reference.
> > > >
> > > > It just feels wrong to me to have the possibility of a dangling fence
> > > > which is never going to get signalled; and it's an easy defensive step
> > > > to make sure it can never happen.
> > > >
> > > > I know it _shouldn't_ happen, but we often put in handling for cases
> > > > which shouldn't happen, because they frequently do happen :-)
> > >
> > > We're not as paranoid with the vblank fences either, so not sure why
> > > we need to be this paranoid with writeback fences. If your driver
> > > grabs anything from the atomic state in ->atomic_check it's buggy
> > > anyway.
> > >
> > > If you want to fix this properly I think we need to move the call to
> > > prepare_signalling() in between atomic_check and atomic_commit. Then I
> > > think it makes sense to also force-complete the fence on error ...
> 
> Well, fair enough. I'm struggling with "that's too paranoid" vs "fix
> it properly" though? Is it a "problem" worth fixing or not?

Up to you to decide that.

> It seems natural to me to do the fence cleanup in the cleanup function
> for the object which owns the fence.
> 
> > >
> > > > > Since for userspace, it should have been failed or a test only case, so
> > > > > writebace fence should not be signaled.
> > > >
> > > > It's not only userspace that can wait on fences (and in fact this
> > > > fence will never even reach userspace if the commit fails), the driver
> > > > may have taken a copy to use for "something".
> > 
> > I forgot to add: you can check this by looking at the fence reference
> > count. A WARN_ON if that's more than 1 on cleanup (but also for the
> > out fences) could be a nice addition.
> 
> Do we really want to be looking at the fence internals directly like
> that?

Wrap it up in a helper like dma_fence_release_private or whatever, which
combines the check and (hopefully final) _put(). Might need a better name.
-Daniel

> 
> Cheers,
> -Brian
> 
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[james qian wang (Arm Technology China)]

On Fri, Aug 02, 2019 at 05:29:20PM +0800, Brian Starkey wrote:
> Hi Lowry,
> 
> On Thu, Aug 01, 2019 at 06:34:08AM +0000, Lowry Li (Arm Technology China) wrote:
> > Hi Brian,
> > 
> > On Wed, Jul 31, 2019 at 09:20:04PM +0800, Brian Starkey wrote:
> > > Hi Lowry,
> > > 
> > > Thanks for this cleanup.
> > > 
> > > On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> > > > During it signals the completion of a writeback job, after releasing
> > > > the out_fence, we'd clear the pointer.
> > > > 
> > > > Check if fence left over in drm_writeback_cleanup_job(), release it.
> > > > 
> > > > Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> > > > ---
> > > >  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
> > > >  1 file changed, 15 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> > > > index ff138b6..43d9e3b 100644
> > > > --- a/drivers/gpu/drm/drm_writeback.c
> > > > +++ b/drivers/gpu/drm/drm_writeback.c
> > > > @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
> > > >  	if (job->fb)
> > > >  		drm_framebuffer_put(job->fb);
> > > >  
> > > > +	if (job->out_fence)
> > > 
> > > I'm thinking it might be a good idea to signal the fence with an error
> > > here, if it's not already signaled. Otherwise, if there's someone
> > > waiting (which there shouldn't be), they're going to be waiting a very
> > > long time :-)
> > > 
> > > Thanks,
> > > -Brian
> > > 
> > Here it happened at atomic_check failed and test only commit. For both
> > cases, the commit has been dropped and it's only a clean up. So here better
> > not be treated as an error case:)
> 
> If anyone else has a reference on the fence, then IMO it absolutely is
> an error to reach this point without the fence being signaled -
> because it means that the fence will never be signaled.
> 
> I don't think the API gives you a way to check if this is the last
> reference, so it's safest to just make sure the fence is signalled
> before dropping the reference.
> 
> It just feels wrong to me to have the possibility of a dangling fence
> which is never going to get signalled; and it's an easy defensive step
> to make sure it can never happen.
> 
> I know it _shouldn't_ happen, but we often put in handling for cases
> which shouldn't happen, because they frequently do happen :-)
> 
> > 
> > Since for userspace, it should have been failed or a test only case, so
> > writebace fence should not be signaled.
> 
> It's not only userspace that can wait on fences (and in fact this
> fence will never even reach userspace if the commit fails), the driver
> may have taken a copy to use for "something".
>

Maybe we can add a wb_fence canceling into complete_signaling() for the
atomic_check failed cleanup like the crtc->out_fence.

Then if in this place we still can got a fence here, that must be a
error we signal and WARN it

Thanks
James

> Cheers,
> -Brian
> 
> > 
> > Best regards,
> > Lowry
> > > > +		dma_fence_put(job->out_fence);
> > > > +
> > > >  	kfree(job);
> > > >  }
> > 
> > -- 
> > Regards
> > Lowry

Re: [PATCH v1 2/2] drm: Clear the fence pointer when writeback job signaled

[Brian Starkey]

Hi Lowry,

Based on Daniel's input, this patch looks fine:

Reviewed-by: Brian Starkey <brian.starkey@arm.com>

I think there's some opportunity for improvement around
prepare_signaling/complete_signaling, but that can be treated as
separate from fixing this bug.

Thanks,
-Brian

On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> During it signals the completion of a writeback job, after releasing
> the out_fence, we'd clear the pointer.
> 
> Check if fence left over in drm_writeback_cleanup_job(), release it.
> 
> Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> ---
>  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index ff138b6..43d9e3b 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
>  	if (job->fb)
>  		drm_framebuffer_put(job->fb);
>  
> +	if (job->out_fence)
> +		dma_fence_put(job->out_fence);
> +
>  	kfree(job);
>  }
>  EXPORT_SYMBOL(drm_writeback_cleanup_job);
> @@ -366,25 +369,29 @@ static void cleanup_work(struct work_struct *work)
>  {
>  	unsigned long flags;
>  	struct drm_writeback_job *job;
> +	struct dma_fence *out_fence;
>  
>  	spin_lock_irqsave(&wb_connector->job_lock, flags);
>  	job = list_first_entry_or_null(&wb_connector->job_queue,
>  				       struct drm_writeback_job,
>  				       list_entry);
> -	if (job) {
> +	if (job)
>  		list_del(&job->list_entry);
> -		if (job->out_fence) {
> -			if (status)
> -				dma_fence_set_error(job->out_fence, status);
> -			dma_fence_signal(job->out_fence);
> -			dma_fence_put(job->out_fence);
> -		}
> -	}
> +
>  	spin_unlock_irqrestore(&wb_connector->job_lock, flags);
>  
>  	if (WARN_ON(!job))
>  		return;
>  
> +	out_fence = job->out_fence;
> +	if (out_fence) {
> +		if (status)
> +			dma_fence_set_error(out_fence, status);
> +		dma_fence_signal(out_fence);
> +		dma_fence_put(out_fence);
> +		job->out_fence = NULL;
> +	}
> +
>  	INIT_WORK(&job->cleanup_work, cleanup_work);
>  	queue_work(system_long_wq, &job->cleanup_work);
>  }
> -- 
> 1.9.1
> 

Re: [v1,2/2] drm: Clear the fence pointer when writeback job signaled

[james qian wang (Arm Technology China)]

On Wed, Jul 31, 2019 at 11:04:45AM +0000, Lowry Li (Arm Technology China) wrote:
> During it signals the completion of a writeback job, after releasing
> the out_fence, we'd clear the pointer.
> 
> Check if fence left over in drm_writeback_cleanup_job(), release it.
> 
> Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com>
> Reviewed-by: Brian Starkey <brian.starkey@arm.com>

Looks good to me.

Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>

will push it to drm-misc-fixes

James

> ---
>  drivers/gpu/drm/drm_writeback.c | 23 +++++++++++++++--------
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index ff138b6..43d9e3b 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -324,6 +324,9 @@ void drm_writeback_cleanup_job(struct drm_writeback_job *job)
>  	if (job->fb)
>  		drm_framebuffer_put(job->fb);
>  
> +	if (job->out_fence)
> +		dma_fence_put(job->out_fence);
> +
>  	kfree(job);
>  }
>  EXPORT_SYMBOL(drm_writeback_cleanup_job);
> @@ -366,25 +369,29 @@ static void cleanup_work(struct work_struct *work)
>  {
>  	unsigned long flags;
>  	struct drm_writeback_job *job;
> +	struct dma_fence *out_fence;
>  
>  	spin_lock_irqsave(&wb_connector->job_lock, flags);
>  	job = list_first_entry_or_null(&wb_connector->job_queue,
>  				       struct drm_writeback_job,
>  				       list_entry);
> -	if (job) {
> +	if (job)
>  		list_del(&job->list_entry);
> -		if (job->out_fence) {
> -			if (status)
> -				dma_fence_set_error(job->out_fence, status);
> -			dma_fence_signal(job->out_fence);
> -			dma_fence_put(job->out_fence);
> -		}
> -	}
> +
>  	spin_unlock_irqrestore(&wb_connector->job_lock, flags);
>  
>  	if (WARN_ON(!job))
>  		return;
>  
> +	out_fence = job->out_fence;
> +	if (out_fence) {
> +		if (status)
> +			dma_fence_set_error(out_fence, status);
> +		dma_fence_signal(out_fence);
> +		dma_fence_put(out_fence);
> +		job->out_fence = NULL;
> +	}
> +
>  	INIT_WORK(&job->cleanup_work, cleanup_work);
>  	queue_work(system_long_wq, &job->cleanup_work);
>  }

Patchwork summary for: linux-renesas-soc

[patchwork-bot+linux-renesas-soc]

Hello:

The following patches were marked "accepted", because they were applied to
geert/renesas-devel (refs/heads/next):

Patch: dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings
  Submitter: Biju Das <biju.das@bp.renesas.com>
  Patchwork: https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=177599

Series: Free the writeback_job when it with an empty fb
  Submitter: Lowry Li (Arm Technology China) <lowry.li@arm.com>
  Patchwork: https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=153341
    Patches: [v1,1/2] drm: Free the writeback_job when it with an empty fb
             [v1,2/2] drm: Clear the fence pointer when writeback job signaled

Total patches: 3

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/pwbot

Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Geert Uytterhoeven]

On Mon, Sep 23, 2019 at 4:31 PM Biju Das <biju.das@bp.renesas.com> wrote:
> Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Rob Herring]

On Mon, 23 Sep 2019 15:30:52 +0100, Biju Das wrote:
> Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
> 
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> ---
>  Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Daniel Lezcano]

On 23/09/2019 16:30, Biju Das wrote:
> Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
> 
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> ---
>  Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> index 9dff7e5..29159f4 100644
> --- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> @@ -11,6 +11,7 @@ Required Properties:
>    - compatible: must contain one or more of the following:
>      - "renesas,tmu-r8a7740" for the r8a7740 TMU
>      - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
> +    - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
>      - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
>      - "renesas,tmu-r8a7778" for the r8a7778 TMU
>      - "renesas,tmu-r8a7779" for the r8a7779 TMU
> 

The patch does not apply on tip/timers

-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

RE: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Biju Das]

Hi Daniel,

Thanks for the feedback. 

> Subject: Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1
> bindings
> 
> On 23/09/2019 16:30, Biju Das wrote:
> > Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
> >
> > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> >  Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > index 9dff7e5..29159f4 100644
> > --- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > @@ -11,6 +11,7 @@ Required Properties:
> >    - compatible: must contain one or more of the following:
> >      - "renesas,tmu-r8a7740" for the r8a7740 TMU
> >      - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
> > +    - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
> >      - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
> >      - "renesas,tmu-r8a7778" for the r8a7778 TMU
> >      - "renesas,tmu-r8a7779" for the r8a7779 TMU
> >
> 
> The patch does not apply on tip/timers

OK. I will rebase on top of tip/timers and will send V2.

Regards,
Biju

Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Daniel Lezcano]

On 03/10/2019 08:38, Biju Das wrote:
> Hi Daniel,
> 
> Thanks for the feedback. 
> 
>> Subject: Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1
>> bindings
>>
>> On 23/09/2019 16:30, Biju Das wrote:
>>> Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
>>>
>>> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
>>> ---
>>>  Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
>>> b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
>>> index 9dff7e5..29159f4 100644
>>> --- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
>>> +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
>>> @@ -11,6 +11,7 @@ Required Properties:
>>>    - compatible: must contain one or more of the following:
>>>      - "renesas,tmu-r8a7740" for the r8a7740 TMU
>>>      - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
>>> +    - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
>>>      - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
>>>      - "renesas,tmu-r8a7778" for the r8a7778 TMU
>>>      - "renesas,tmu-r8a7779" for the r8a7779 TMU
>>>
>>
>> The patch does not apply on tip/timers
> 
> OK. I will rebase on top of tip/timers and will send V2.

Great, thanks


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Oct 3, 2019 at 6:09 AM Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> On 23/09/2019 16:30, Biju Das wrote:
> > Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
> >
> > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> > ---
> >  Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > index 9dff7e5..29159f4 100644
> > --- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > @@ -11,6 +11,7 @@ Required Properties:
> >    - compatible: must contain one or more of the following:
> >      - "renesas,tmu-r8a7740" for the r8a7740 TMU
> >      - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
> > +    - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
> >      - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
> >      - "renesas,tmu-r8a7778" for the r8a7778 TMU
> >      - "renesas,tmu-r8a7779" for the r8a7779 TMU
> >
>
> The patch does not apply on tip/timers

That's expected, as I queued the previous change in
renesas-dt-bindings-for-v5.5, cfr.
https://lore.kernel.org/linux-renesas-soc/244ca7ac-54d1-d07d-762f-e832b0e2a267@linaro.org/

Do you want me to know this in renesas-dt-bindings-for-v5.5?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Biju Das]

Hi Geert, Daniel,

Any update on the below binding patch?

Regards,
Biju
> -----Original Message-----
> From: Geert Uytterhoeven <geert@linux-m68k.org>
> Sent: Thursday, October 3, 2019 7:51 AM
> To: Daniel Lezcano <daniel.lezcano@linaro.org>
> Cc: Biju Das <biju.das@bp.renesas.com>; Rob Herring
> <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Thomas
> Gleixner <tglx@linutronix.de>; open list:OPEN FIRMWARE AND FLATTENED
> DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Geert Uytterhoeven
> <geert+renesas@glider.be>; Simon Horman <horms@verge.net.au>; Chris
> Paterson <Chris.Paterson2@renesas.com>; Fabrizio Castro
> <fabrizio.castro@bp.renesas.com>; Linux-Renesas <linux-renesas-
> soc@vger.kernel.org>
> Subject: Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1
> bindings
> 
> Hi Daniel,
> 
> On Thu, Oct 3, 2019 at 6:09 AM Daniel Lezcano <daniel.lezcano@linaro.org>
> wrote:
> > On 23/09/2019 16:30, Biju Das wrote:
> > > Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
> > >
> > > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> > > ---
> > >  Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > index 9dff7e5..29159f4 100644
> > > --- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > @@ -11,6 +11,7 @@ Required Properties:
> > >    - compatible: must contain one or more of the following:
> > >      - "renesas,tmu-r8a7740" for the r8a7740 TMU
> > >      - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
> > > +    - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
> > >      - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
> > >      - "renesas,tmu-r8a7778" for the r8a7778 TMU
> > >      - "renesas,tmu-r8a7779" for the r8a7779 TMU
> > >
> >
> > The patch does not apply on tip/timers
> 
> That's expected, as I queued the previous change in renesas-dt-bindings-for-
> v5.5, cfr.
> https://lore.kernel.org/linux-renesas-soc/244ca7ac-54d1-d07d-762f-
> e832b0e2a267@linaro.org/
> 
> Do you want me to know this in renesas-dt-bindings-for-v5.5?

Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Geert Uytterhoeven]

Hi Biju,

On Thu, Nov 21, 2019 at 9:52 AM Biju Das <biju.das@bp.renesas.com> wrote:
> Any update on the below binding patch?

If it won't appear in v5.5-rc1, my plan is to queue it in renesas-devel
for v5.6.

> > -----Original Message-----
> > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > Sent: Thursday, October 3, 2019 7:51 AM
> > To: Daniel Lezcano <daniel.lezcano@linaro.org>
> > Cc: Biju Das <biju.das@bp.renesas.com>; Rob Herring
> > <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Thomas
> > Gleixner <tglx@linutronix.de>; open list:OPEN FIRMWARE AND FLATTENED
> > DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Geert Uytterhoeven
> > <geert+renesas@glider.be>; Simon Horman <horms@verge.net.au>; Chris
> > Paterson <Chris.Paterson2@renesas.com>; Fabrizio Castro
> > <fabrizio.castro@bp.renesas.com>; Linux-Renesas <linux-renesas-
> > soc@vger.kernel.org>
> > Subject: Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1
> > bindings
> >
> > Hi Daniel,
> >
> > On Thu, Oct 3, 2019 at 6:09 AM Daniel Lezcano <daniel.lezcano@linaro.org>
> > wrote:
> > > On 23/09/2019 16:30, Biju Das wrote:
> > > > Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
> > > >
> > > > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> > > > ---
> > > >  Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > > b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > > index 9dff7e5..29159f4 100644
> > > > --- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > > +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > > @@ -11,6 +11,7 @@ Required Properties:
> > > >    - compatible: must contain one or more of the following:
> > > >      - "renesas,tmu-r8a7740" for the r8a7740 TMU
> > > >      - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
> > > > +    - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
> > > >      - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
> > > >      - "renesas,tmu-r8a7778" for the r8a7778 TMU
> > > >      - "renesas,tmu-r8a7779" for the r8a7779 TMU
> > > >
> > >
> > > The patch does not apply on tip/timers
> >
> > That's expected, as I queued the previous change in renesas-dt-bindings-for-
> > v5.5, cfr.
> > https://lore.kernel.org/linux-renesas-soc/244ca7ac-54d1-d07d-762f-
> > e832b0e2a267@linaro.org/
> >
> > Do you want me to know this in renesas-dt-bindings-for-v5.5?
>


-- 
Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1 bindings

[Geert Uytterhoeven]

On Thu, Nov 21, 2019 at 9:55 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Nov 21, 2019 at 9:52 AM Biju Das <biju.das@bp.renesas.com> wrote:
> > Any update on the below binding patch?
>
> If it won't appear in v5.5-rc1, my plan is to queue it in renesas-devel
> for v5.6.

Queued.


> > > -----Original Message-----
> > > From: Geert Uytterhoeven <geert@linux-m68k.org>
> > > Sent: Thursday, October 3, 2019 7:51 AM
> > > To: Daniel Lezcano <daniel.lezcano@linaro.org>
> > > Cc: Biju Das <biju.das@bp.renesas.com>; Rob Herring
> > > <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Thomas
> > > Gleixner <tglx@linutronix.de>; open list:OPEN FIRMWARE AND FLATTENED
> > > DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; Geert Uytterhoeven
> > > <geert+renesas@glider.be>; Simon Horman <horms@verge.net.au>; Chris
> > > Paterson <Chris.Paterson2@renesas.com>; Fabrizio Castro
> > > <fabrizio.castro@bp.renesas.com>; Linux-Renesas <linux-renesas-
> > > soc@vger.kernel.org>
> > > Subject: Re: [PATCH] dt-bindings: timer: renesas: tmu: Document r8a774b1
> > > bindings
> > >
> > > Hi Daniel,
> > >
> > > On Thu, Oct 3, 2019 at 6:09 AM Daniel Lezcano <daniel.lezcano@linaro.org>
> > > wrote:
> > > > On 23/09/2019 16:30, Biju Das wrote:
> > > > > Document RZ/G2N (R8A774B1) SoC in the Renesas TMU bindings.
> > > > >
> > > > > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> > > > > ---
> > > > >  Documentation/devicetree/bindings/timer/renesas,tmu.txt | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > > > b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > > > index 9dff7e5..29159f4 100644
> > > > > --- a/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > > > +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.txt
> > > > > @@ -11,6 +11,7 @@ Required Properties:
> > > > >    - compatible: must contain one or more of the following:
> > > > >      - "renesas,tmu-r8a7740" for the r8a7740 TMU
> > > > >      - "renesas,tmu-r8a774a1" for the r8a774A1 TMU
> > > > > +    - "renesas,tmu-r8a774b1" for the r8a774B1 TMU
> > > > >      - "renesas,tmu-r8a774c0" for the r8a774C0 TMU
> > > > >      - "renesas,tmu-r8a7778" for the r8a7778 TMU
> > > > >      - "renesas,tmu-r8a7779" for the r8a7779 TMU
> > > > >
> > > >
> > > > The patch does not apply on tip/timers
> > >
> > > That's expected, as I queued the previous change in renesas-dt-bindings-for-
> > > v5.5, cfr.
> > > https://lore.kernel.org/linux-renesas-soc/244ca7ac-54d1-d07d-762f-
> > > e832b0e2a267@linaro.org/
> > >
> > > Do you want me to know this in renesas-dt-bindings-for-v5.5?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds