Re: [RFC v4 09/11] drm/amdgpu: Move in_gpu_reset into reset_domain

[Christian König]

Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:

We should have a single instance per entrire reset domain.

Signed-off-by: Andrey Grodzovsky 
Suggested-by: Lijo Lazar 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  7 ++-
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c  |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h  |  1 +
  drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c  |  4 ++--
  drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c  |  4 ++--
  6 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index ddfbcc8fd3d3..b89406b01694 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1056,7 +1056,6 @@ struct amdgpu_device {
boolin_s4;
boolin_s0ix;
  
-	atomic_t 			in_gpu_reset;

enum pp_mp1_state   mp1_state;
struct amdgpu_doorbell_index doorbell_index;
  
@@ -1463,8 +1462,6 @@ static inline bool amdgpu_is_tmz(struct amdgpu_device *adev)

 return adev->gmc.tmz_enabled;
  }
  
-static inline int amdgpu_in_reset(struct amdgpu_device *adev)

-{
-   return atomic_read(&adev->in_gpu_reset);
-}
+int amdgpu_in_reset(struct amdgpu_device *adev);
+
  #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index dcbb175d336f..e05d7cbefd2c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3554,7 +3554,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
mutex_init(&adev->mn_lock);
mutex_init(&adev->virt.vf_errors.lock);
hash_init(adev->mn_hash);
-   atomic_set(&adev->in_gpu_reset, 0);
mutex_init(&adev->psp.mutex);
mutex_init(&adev->notifier_lock);
  
@@ -4829,7 +4828,7 @@ int amdgpu_do_asic_reset(struct list_head *device_list_handle,

  static void amdgpu_device_lock_adev(struct amdgpu_device *adev,
struct amdgpu_hive_info *hive)
  {
-   atomic_set(&adev->in_gpu_reset, 1);
+   atomic_set(&adev->reset_domain->in_gpu_reset, 1);
  
  	if (hive) {

down_write_nest_lock(&adev->reset_domain->sem, 
&hive->hive_lock);
@@ -4854,7 +4853,7 @@ static void amdgpu_device_unlock_adev(struct 
amdgpu_device *adev)
  {
amdgpu_vf_error_trans_all(adev);
adev->mp1_state = PP_MP1_STATE_NONE;
-   atomic_set(&adev->in_gpu_reset, 0);
+   atomic_set(&adev->reset_domain->in_gpu_reset, 0);
up_write(&adev->reset_domain->sem);
  }
  
@@ -5699,6 +5698,11 @@ void amdgpu_device_invalidate_hdp(struct amdgpu_device *adev,

amdgpu_asic_invalidate_hdp(adev, ring);
  }
  
+int amdgpu_in_reset(struct amdgpu_device *adev)

+{
+   return atomic_read(&adev->reset_domain->in_gpu_reset);
+   }
+   
  /**
   * amdgpu_device_halt() - bring hardware to some kind of halt state
   *
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
index c0988c804459..5ab72c3bfbda 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
@@ -131,6 +131,7 @@ struct amdgpu_reset_domain 
*amdgpu_reset_create_reset_domain(enum amdgpu_reset_d
  
  	}
  
+	atomic_set(&reset_domain->in_gpu_reset, 0);

init_rwsem(&reset_domain->sem);
  
  	return reset_domain;

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
index 80f918e87d4f..ea6fc98ea927 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
@@ -81,6 +81,7 @@ struct amdgpu_reset_domain {
struct workqueue_struct *wq;
enum amdgpu_reset_domain_type type;
struct rw_semaphore sem;
+   atomic_t in_gpu_reset;
  };
  
  
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c

index 4e23c29e665c..b81acf59870c 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
@@ -259,7 +259,7 @@ static void xgpu_ai_mailbox_flr_work(struct work_struct 
*work)
 * otherwise the mailbox msg will be ruined/reseted by
 * the VF FLR.
 */
-   if (atomic_cmpxchg(&adev->in_gpu_reset, 0, 1) != 0)
+   if (atomic_cmpxchg(&adev->reset_domain->in_gpu_reset, 0, 1) != 0)
return;
  
  	down_write(&adev->reset_domain->sem);

@@ -277,7 +277,7 @@ static void xgpu_ai_mailbox_flr_work(struct work_struct 
*work)
} while (timeout > 1);
  
  flr_done:

-   atomic_set(&adev->in_gpu_reset, 0);
+   atomic_set(&adev->reset_domain->in_gpu_reset, 0);
up_write(&adev->reset_domain->sem);
  
  	/* Trigger recovery for world switch failure if no TDR */

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

Re: [RFC v4 10/11] drm/amdgpu: Rework amdgpu_device_lock_adev

[Christian König]

Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:

This functions needs to be split into 2 parts where
one is called only once for locking single instance of
reset_domain's sem and reset flag and the other part
which handles MP1 states should still be called for
each device in XGMI hive.

Signed-off-by: Andrey Grodzovsky 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 48 --
  1 file changed, 35 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e05d7cbefd2c..aaecf0797484 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4825,16 +4825,20 @@ int amdgpu_do_asic_reset(struct list_head 
*device_list_handle,
return r;
  }
  
-static void amdgpu_device_lock_adev(struct amdgpu_device *adev,

-   struct amdgpu_hive_info *hive)
+static void amdgpu_device_lock_reset_domain(struct amdgpu_reset_domain 
*reset_domain,
+   struct amdgpu_hive_info *hive)
  {
-   atomic_set(&adev->reset_domain->in_gpu_reset, 1);
+   atomic_set(&reset_domain->in_gpu_reset, 1);
  
  	if (hive) {

-   down_write_nest_lock(&adev->reset_domain->sem, 
&hive->hive_lock);
+   down_write_nest_lock(&reset_domain->sem, &hive->hive_lock);
} else {
-   down_write(&adev->reset_domain->sem);
+   down_write(&reset_domain->sem);
}
+}
+
+static void amdgpu_device_set_mp1_state(struct amdgpu_device *adev)
+{
  
  	switch (amdgpu_asic_reset_method(adev)) {

case AMD_RESET_METHOD_MODE1:
@@ -4849,14 +4853,19 @@ static void amdgpu_device_lock_adev(struct 
amdgpu_device *adev,
}
  }
  
-static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)

+static void amdgpu_device_unset_mp1_state(struct amdgpu_device *adev)
  {
amdgpu_vf_error_trans_all(adev);
adev->mp1_state = PP_MP1_STATE_NONE;
-   atomic_set(&adev->reset_domain->in_gpu_reset, 0);
-   up_write(&adev->reset_domain->sem);
  }
  
+static void amdgpu_device_unlock_reset_domain(struct amdgpu_reset_domain *reset_domain)

+{
+   atomic_set(&reset_domain->in_gpu_reset, 0);
+   up_write(&reset_domain->sem);
+}


I would move this into amdgpu_reset.c and call it 
amdgpu_reset_domain_unlock().


Same of course for amdgpu_reset_domain_lock()...

Apart from that looks good to me,
Christian.


+
+
  static void amdgpu_device_resume_display_audio(struct amdgpu_device *adev)
  {
struct pci_dev *p = NULL;
@@ -5060,10 +5069,15 @@ int amdgpu_device_gpu_recover_imp(struct amdgpu_device 
*adev,
device_list_handle = &device_list;
}
  
+	/* We need to lock reset domain only once both for XGMI and single device */

+   tmp_adev = list_first_entry(device_list_handle, struct amdgpu_device,
+   reset_list);
+   amdgpu_device_lock_reset_domain(tmp_adev->reset_domain, hive);
+
/* block all schedulers and reset given job's ring */
list_for_each_entry(tmp_adev, device_list_handle, reset_list) {
  
-		amdgpu_device_lock_adev(tmp_adev, hive);

+   amdgpu_device_set_mp1_state(tmp_adev);
  
  		/*

 * Try to put the audio codec into suspend state
@@ -5213,9 +5227,14 @@ int amdgpu_device_gpu_recover_imp(struct amdgpu_device 
*adev,
  
  		if (audio_suspended)

amdgpu_device_resume_display_audio(tmp_adev);
-   amdgpu_device_unlock_adev(tmp_adev);
+
+   amdgpu_device_unset_mp1_state(tmp_adev);
}
  
+	tmp_adev = list_first_entry(device_list_handle, struct amdgpu_device,

+   reset_list);
+   amdgpu_device_unlock_reset_domain(tmp_adev->reset_domain);
+
if (hive) {
mutex_unlock(&hive->hive_lock);
amdgpu_put_xgmi_hive(hive);
@@ -5477,7 +5496,8 @@ pci_ers_result_t amdgpu_pci_error_detected(struct pci_dev 
*pdev, pci_channel_sta
 * Locking adev->reset_domain->sem will prevent any external 
access
 * to GPU during PCI error recovery
 */
-   amdgpu_device_lock_adev(adev, NULL);
+   amdgpu_device_lock_reset_domain(adev->reset_domain, NULL);
+   amdgpu_device_set_mp1_state(adev);
  
  		/*

 * Block any work scheduling as we do for regular GPU reset
@@ -5584,7 +5604,8 @@ pci_ers_result_t amdgpu_pci_slot_reset(struct pci_dev 
*pdev)
DRM_INFO("PCIe error recovery succeeded\n");
} else {
DRM_ERROR("PCIe error recovery failed, err:%d", r);
-   amdgpu_device_unlock_adev(adev);
+   amdgpu_device_unset_mp1_state(adev);
+   amdgpu_device_unlock_reset_domain(adev->reset_domain);
}
  
  	return r ? PCI_ERS_RESULT_DISCONNECT : PCI_ERS_RESULT_RECOVERED;

@@ -5621,

Re: [RFC v4 11/11] Revert 'drm/amdgpu: annotate a false positive recursive locking'

[Christian König]

Am 09.02.22 um 01:23 schrieb Andrey Grodzovsky:

Since we have a single instance of reset semaphore which we
lock only once even for XGMI hive we don't need the nested
locking hint anymore.

Signed-off-by: Andrey Grodzovsky 


Oh, yes please :)

Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 --
  1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index aaecf0797484..75d0dd289023 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4825,16 +4825,10 @@ int amdgpu_do_asic_reset(struct list_head 
*device_list_handle,
return r;
  }
  
-static void amdgpu_device_lock_reset_domain(struct amdgpu_reset_domain *reset_domain,

-   struct amdgpu_hive_info *hive)
+static void amdgpu_device_lock_reset_domain(struct amdgpu_reset_domain 
*reset_domain)
  {
atomic_set(&reset_domain->in_gpu_reset, 1);
-
-   if (hive) {
-   down_write_nest_lock(&reset_domain->sem, &hive->hive_lock);
-   } else {
-   down_write(&reset_domain->sem);
-   }
+   down_write(&reset_domain->sem);
  }
  
  static void amdgpu_device_set_mp1_state(struct amdgpu_device *adev)

@@ -5072,7 +5066,7 @@ int amdgpu_device_gpu_recover_imp(struct amdgpu_device 
*adev,
/* We need to lock reset domain only once both for XGMI and single 
device */
tmp_adev = list_first_entry(device_list_handle, struct amdgpu_device,
reset_list);
-   amdgpu_device_lock_reset_domain(tmp_adev->reset_domain, hive);
+   amdgpu_device_lock_reset_domain(tmp_adev->reset_domain);
  
  	/* block all schedulers and reset given job's ring */

list_for_each_entry(tmp_adev, device_list_handle, reset_list) {
@@ -5496,7 +5490,7 @@ pci_ers_result_t amdgpu_pci_error_detected(struct pci_dev 
*pdev, pci_channel_sta
 * Locking adev->reset_domain->sem will prevent any external 
access
 * to GPU during PCI error recovery
 */
-   amdgpu_device_lock_reset_domain(adev->reset_domain, NULL);
+   amdgpu_device_lock_reset_domain(adev->reset_domain);
amdgpu_device_set_mp1_state(adev);
  
  		/*

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix flag query to not modify state

[Tvrtko Ursulin]

On 08/02/2022 18:53, John Harrison wrote:

On 2/8/2022 01:39, Tvrtko Ursulin wrote:

On 08/02/2022 02:07, john.c.harri...@intel.com wrote:

From: John Harrison 

A flag query helper was actually writing to the flags word rather than
just reading. Fix that. Also update the function's comment as it was
out of date.

Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

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

index b3a429a92c0d..d9f4218f5ef4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -174,11 +174,8 @@ static inline void init_sched_state(struct 
intel_context *ce)

  __maybe_unused
  static bool sched_state_is_init(struct intel_context *ce)
  {
-    /*
- * XXX: Kernel contexts can have SCHED_STATE_NO_LOCK_REGISTERED 
after

- * suspend.
- */
-    return !(ce->guc_state.sched_state &=
+    /* Kernel contexts can have SCHED_STATE_REGISTERED after 
suspend. */

+    return !(ce->guc_state.sched_state &
   ~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
  }


Looks important - what are the consequences?

Supposedly nothing.

The test was only ever used inside a BUG_ON during context registration. 
Rather than asserting that the condition was true, it was making the 
condition true. So, in theory, there was no consequence because we 
should never have hit a BUG_ON anyway. Which means the write should 
always have been a no-op.




Needs Cc: stable for 5.16?
Meaning "Cc: "? Or is there anything required to 
specify 5.16?


It would have been:

Cc:  # v5.16+

You can use "dim fixes " and it will output you the suggested tags.

But given what you say about it having no impact even in debug builds 
then it's not needed. Just note that explaining the impact in the commit 
message when Fixes: tag is present is very desirable in general. Without 
it maintainers have a hard time assessing and highlighting important 
stuff in pull requests. So I would at least ask for respin with updated 
commit message explaining there is no consequence and why cc stable is 
not needed.


Regards,

Tvrtko

Re: [PATCH v7 1/6] drm: Add arch arm64 for drm_clflush_virt_range

[Tvrtko Ursulin]

On 09/02/2022 06:30, Michael Cheng wrote:

Add arm64 support for drm_clflush_virt_range. dcache_clean_inval_poc
performs a flush by first performing a clean, follow by an invalidation
operation.

v2 (Michael Cheng): Use correct macro for cleaning and invalidation the
dcache.

Signed-off-by: Michael Cheng 
---
  drivers/gpu/drm/drm_cache.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index f19d9acbe959..94b3cc3fd482 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -39,6 +39,10 @@
  /* A small bounce buffer that fits on the stack. */
  #define MEMCPY_BOUNCE_SIZE 128
  
+#if defined(CONFIG_ARM64)

+#include 
+#endif
+


I think this likely should be a single, arch unconditional:

#include 

Probably it just happens that some other include pulls in clflushopt for 
x86.


Regards,

Tvrtko


  #if defined(CONFIG_X86)
  #include 
  
@@ -176,6 +180,10 @@ drm_clflush_virt_range(void *addr, unsigned long length)
  
  	if (wbinvd_on_all_cpus())

pr_err("Timed out waiting for cache flush\n");
+
+#elif defined(CONFIG_ARM64)
+   void *end = addr + length;
+   dcache_clean_inval_poc((unsigned long)addr, (unsigned long)end);
  #else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);

Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller

[Maxime Ripard]

On Fri, Feb 04, 2022 at 12:41:37AM +0800, Sui Jingfeng wrote:
> > > +static int lsdc_primary_plane_atomic_check(struct drm_plane *plane,
> > > +struct drm_atomic_state *state)
> > > +{
> > > + struct drm_device *ddev = plane->dev;
> > > + struct lsdc_device *ldev = to_lsdc(ddev);
> > > + struct drm_plane_state *old_plane_state = 
> > > drm_atomic_get_old_plane_state(state, plane);
> > > + struct drm_plane_state *new_plane_state = 
> > > drm_atomic_get_new_plane_state(state, plane);
> > > + struct drm_framebuffer *new_fb = new_plane_state->fb;
> > > + struct drm_framebuffer *old_fb = old_plane_state->fb;
> > > + struct drm_crtc *crtc = new_plane_state->crtc;
> > > + u32 new_format = new_fb->format->format;
> > > + struct drm_crtc_state *new_crtc_state;
> > > + struct lsdc_crtc_state *priv_crtc_state;
> > > + int ret;
> > > +
> > > + if (!crtc)
> > > + return 0;
> > > +
> > > + new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> > > + if (WARN_ON(!new_crtc_state))
> > > + return -EINVAL;
> > > +
> > > + priv_crtc_state = to_lsdc_crtc_state(new_crtc_state);
> > > +
> > > + ret = drm_atomic_helper_check_plane_state(new_plane_state,
> > > +   new_crtc_state,
> > > +   DRM_PLANE_HELPER_NO_SCALING,
> > > +   DRM_PLANE_HELPER_NO_SCALING,
> > > +   false,
> > > +   true);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /*
> > > +  * Require full modeset if enabling or disabling a plane,
> > > +  * or changing its position, size, depth or format.
> > > +  */
> > > + if ((!new_fb || !old_fb ||
> > > +  old_plane_state->crtc_x != new_plane_state->crtc_x ||
> > > +  old_plane_state->crtc_y != new_plane_state->crtc_y ||
> > > +  old_plane_state->crtc_w != new_plane_state->crtc_w ||
> > > +  old_plane_state->crtc_h != new_plane_state->crtc_h ||
> > > +  old_fb->format->format != new_format))
> > > + new_crtc_state->mode_changed = true;
> > > +
> > > +
> > > + priv_crtc_state->pix_fmt = lsdc_primary_get_default_format(crtc);
> > Storing the pixel format in the CRTC state is weird? What would happen
> > if you have a primary plane and a cursor in different formats?
> > 
> > Also, reading the default format from a register doesn't look right.
> > atomic_check can occur at any time, including before a previous commit,
> > or while the hardware is disabled. You should rely on either a constant
> > or the previous state here.
> > 
> Currently, private CRTC state(priv_crtc_state) is not get used by the cursor's
> atomic_check() and atomic_update(). I means this is only for the primary 
> plane.
> And both and the primary and the cursor using  XRGB format, what I really
> want here is let the atomic_update to update the framebuffer's format, because
> the firmware (pmon) of some board set the framebuffer's format as RGB565.

atomic_update will be called each time the plane state is changed, so it
won't be an issue: when the first state will be committed, your
atomic_update function will be called and thus you'll overwrite what was
left of the firmware setup.

> If the hardware's format is same with the plane state, then there is no need 
> to
> update the FB's format register, save a function call, right?

My point was more about the fact that you're using the wrong abstraction
there. The format is a property of the plane, not from the CRTC. In KMS
(and in most drivers), you can have multiple planes with different
formats all attached to the same CRTC just fine.

Maxime


signature.asc
Description: PGP signature

[PATCH] gpu: drm: msm: use div64_u64() instead of do_div()

[Qing Wang]

From: Wang Qing 

do_div() does a 64-by-32 division.
When the divisor is u64, do_div() truncates it to 32 bits, this means it
can test non-zero and be truncated to zero for division.

fix do_div.cocci warning:
do_div() does a 64-by-32 division, please consider using div64_u64 instead.

Signed-off-by: Wang Qing 
---
 drivers/gpu/drm/msm/msm_gpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 2c1049c..aa4617b
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -648,7 +648,7 @@ static void retire_submit(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring,
/* Calculate the clock frequency from the number of CP cycles */
if (elapsed) {
clock = (stats->cpcycles_end - stats->cpcycles_start) * 1000;
-   do_div(clock, elapsed);
+   div64_u64(clock, elapsed);
}
 
trace_msm_gpu_submit_retired(submit, elapsed, clock,
-- 
2.7.4

Re: [PATCH 5/5] spi: make remove callback a void function

[Mark Brown]

On Sun, Jan 23, 2022 at 06:52:01PM +0100, Uwe Kleine-König wrote:
> The value returned by an spi driver's remove function is mostly ignored.
> (Only an error message is printed if the value is non-zero that the
> error is ignored.)
> 
> So change the prototype of the remove function to return no value. This
> way driver authors are not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.

I was going to apply this but it needs rebasing against current code
unfortunately.


signature.asc
Description: PGP signature

[PATCH] video: fbdev: replace snprintf with sysfs_emit

[davidcomponentone]

From: Yang Guang 

coccinelle report:
./drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c:
202:8-16: WARNING: use scnprintf or sprintf
./drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c:
172:8-16: WARNING: use scnprintf or sprintf

Use sysfs_emit instead of scnprintf or sprintf makes more sense.

Reported-by: Zeal Robot 
Signed-off-by: Yang Guang 
Signed-off-by: David Yang 
---
 .../video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
index 3db0232c31ab..155b3f8ad158 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
@@ -169,7 +169,7 @@ static ssize_t tpo_td043_vmirror_show(struct device *dev,
 {
struct panel_drv_data *ddata = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%d\n", ddata->vmirror);
+   return sysfs_emit(buf, "%d\n", ddata->vmirror);
 }
 
 static ssize_t tpo_td043_vmirror_store(struct device *dev,
@@ -199,7 +199,7 @@ static ssize_t tpo_td043_mode_show(struct device *dev,
 {
struct panel_drv_data *ddata = dev_get_drvdata(dev);
 
-   return snprintf(buf, PAGE_SIZE, "%d\n", ddata->mode);
+   return sysfs_emit(buf, "%d\n", ddata->mode);
 }
 
 static ssize_t tpo_td043_mode_store(struct device *dev,
-- 
2.30.2

Re: [syzbot] WARNING in component_del

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any 
issue:

Reported-and-tested-by: syzbot+60df062e1c41940ca...@syzkaller.appspotmail.com

Tested on:

commit: 555f3d7b Merge tag '5.17-rc3-ksmbd-server-fixes' of gi..
git tree:   upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=266de9da75c71a45
dashboard link: https://syzkaller.appspot.com/bug?extid=60df062e1c41940cae0f
compiler:   gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for 
Debian) 2.35.2
patch:  https://syzkaller.appspot.com/x/patch.diff?x=111f742870

Note: testing is done by a robot and is best-effort only.

[PATCH] drm/bridge: anx7625: Fix overflow issue on reading EDID

[Pin-Yen Lin]

The length of EDID block can be longer than 256 bytes, so we should use
`int` instead of `u8` for the `edid_pos` variable.

Signed-off-by: Pin-Yen Lin 
---

 drivers/gpu/drm/bridge/analogix/anx7625.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 2346dbcc505f..e596cacce9e3 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -846,7 +846,8 @@ static int segments_edid_read(struct anx7625_data *ctx,
 static int sp_tx_edid_read(struct anx7625_data *ctx,
   u8 *pedid_blocks_buf)
 {
-   u8 offset, edid_pos;
+   u8 offset;
+   int edid_pos;
int count, blocks_num;
u8 pblock_buf[MAX_DPCD_BUFFER_SIZE];
u8 i, j;
-- 
2.35.0.263.gb82422642f-goog

drm/ttm: moving the LRU into the resource

[Christian König]

Hi guys,

so hopefully the last round for this set.

It fixes both a long outstanding problem with TTM and resource
allocation as well as Bas's new performance problem with RADV.

Please review and comment.

Thanks,
Christian.

[PATCH 3/9] drm/ttm: add resource iterator v2

[Christian König]

Instead of duplicating that at different places add an iterator over all
the resources in a resource manager.

v2: add lockdep annotation and kerneldoc

Signed-off-by: Christian König 
Tested-by: Bas Nieuwenhuizen 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 41 ++---
 drivers/gpu/drm/ttm/ttm_device.c   | 26 +++-
 drivers/gpu/drm/ttm/ttm_resource.c | 49 ++
 include/drm/ttm/ttm_resource.h | 23 ++
 4 files changed, 99 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index cb0fa932d495..599be3dda8a9 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -579,38 +579,29 @@ int ttm_mem_evict_first(struct ttm_device *bdev,
struct ww_acquire_ctx *ticket)
 {
struct ttm_buffer_object *bo = NULL, *busy_bo = NULL;
+   struct ttm_resource_cursor cursor;
struct ttm_resource *res;
bool locked = false;
-   unsigned i;
int ret;
 
spin_lock(&bdev->lru_lock);
-   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
-   list_for_each_entry(res, &man->lru[i], lru) {
-   bool busy;
-
-   bo = res->bo;
-   if (!ttm_bo_evict_swapout_allowable(bo, ctx, place,
-   &locked, &busy)) {
-   if (busy && !busy_bo && ticket !=
-   dma_resv_locking_ctx(bo->base.resv))
-   busy_bo = bo;
-   continue;
-   }
-
-   if (!ttm_bo_get_unless_zero(bo)) {
-   if (locked)
-   dma_resv_unlock(bo->base.resv);
-   continue;
-   }
-   break;
+   ttm_resource_manager_for_each_res(man, &cursor, res) {
+   bool busy;
+
+   if (!ttm_bo_evict_swapout_allowable(res->bo, ctx, place,
+   &locked, &busy)) {
+   if (busy && !busy_bo && ticket !=
+   dma_resv_locking_ctx(bo->base.resv))
+   busy_bo = res->bo;
+   continue;
}
 
-   /* If the inner loop terminated early, we have our candidate */
-   if (&res->lru != &man->lru[i])
-   break;
-
-   bo = NULL;
+   if (!ttm_bo_get_unless_zero(res->bo)) {
+   if (locked)
+   dma_resv_unlock(res->bo->base.resv);
+   continue;
+   }
+   bo = res->bo;
}
 
if (!bo) {
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index ba35887147ba..a0562ab386f5 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -142,10 +142,10 @@ EXPORT_SYMBOL(ttm_global_swapout);
 int ttm_device_swapout(struct ttm_device *bdev, struct ttm_operation_ctx *ctx,
   gfp_t gfp_flags)
 {
+   struct ttm_resource_cursor cursor;
struct ttm_resource_manager *man;
-   struct ttm_buffer_object *bo;
struct ttm_resource *res;
-   unsigned i, j;
+   unsigned i;
int ret;
 
spin_lock(&bdev->lru_lock);
@@ -154,20 +154,16 @@ int ttm_device_swapout(struct ttm_device *bdev, struct 
ttm_operation_ctx *ctx,
if (!man || !man->use_tt)
continue;
 
-   for (j = 0; j < TTM_MAX_BO_PRIORITY; ++j) {
-   list_for_each_entry(res, &man->lru[j], lru) {
-   uint32_t num_pages;
-
-   bo = res->bo;
-   num_pages = PFN_UP(bo->base.size);
+   ttm_resource_manager_for_each_res(man, &cursor, res) {
+   struct ttm_buffer_object *bo = res->bo;
+   uint32_t num_pages = PFN_UP(bo->base.size);
 
-   ret = ttm_bo_swapout(bo, ctx, gfp_flags);
-   /* ttm_bo_swapout has dropped the lru_lock */
-   if (!ret)
-   return num_pages;
-   if (ret != -EBUSY)
-   return ret;
-   }
+   ret = ttm_bo_swapout(bo, ctx, gfp_flags);
+   /* ttm_bo_swapout has dropped the lru_lock */
+   if (!ret)
+   return num_pages;
+   if (ret != -EBUSY)
+   return ret;
}
}
spin_unlock(&bdev->lru_lock);
diff --git a/dr

[PATCH 1/9] drm/ttm: add common accounting to the resource mgr v3

[Christian König]

It makes sense to have this in the common manager for debugging and
accounting of how much resources are used.

v2: cleanup kerneldoc a bit
v3: drop the atomic, update counter under lock instead

Signed-off-by: Christian König 
Reviewed-by: Huang Rui  (v1)
Tested-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/ttm/ttm_resource.c | 30 ++
 include/drm/ttm/ttm_resource.h | 11 +--
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index 68344c90549b..7f9ec64ebaba 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -41,6 +41,8 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
const struct ttm_place *place,
struct ttm_resource *res)
 {
+   struct ttm_resource_manager *man;
+
res->start = 0;
res->num_pages = PFN_UP(bo->base.size);
res->mem_type = place->mem_type;
@@ -50,6 +52,11 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
res->bus.is_iomem = false;
res->bus.caching = ttm_cached;
res->bo = bo;
+
+   man = ttm_manager_type(bo->bdev, place->mem_type);
+   spin_lock(&bo->bdev->lru_lock);
+   man->usage += bo->base.size;
+   spin_unlock(&bo->bdev->lru_lock);
 }
 EXPORT_SYMBOL(ttm_resource_init);
 
@@ -65,6 +72,9 @@ EXPORT_SYMBOL(ttm_resource_init);
 void ttm_resource_fini(struct ttm_resource_manager *man,
   struct ttm_resource *res)
 {
+   spin_lock(&man->bdev->lru_lock);
+   man->usage -= res->bo->base.size;
+   spin_unlock(&man->bdev->lru_lock);
 }
 EXPORT_SYMBOL(ttm_resource_fini);
 
@@ -166,6 +176,7 @@ void ttm_resource_manager_init(struct ttm_resource_manager 
*man,
spin_lock_init(&man->move_lock);
man->bdev = bdev;
man->size = p_size;
+   man->usage = 0;
 
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i)
INIT_LIST_HEAD(&man->lru[i]);
@@ -226,6 +237,24 @@ int ttm_resource_manager_evict_all(struct ttm_device *bdev,
 }
 EXPORT_SYMBOL(ttm_resource_manager_evict_all);
 
+/**
+ * ttm_resource_manager_usage
+ *
+ * @man: A memory manager object.
+ *
+ * Return how many resources are currently used.
+ */
+uint64_t ttm_resource_manager_usage(struct ttm_resource_manager *man)
+{
+   uint64_t usage;
+
+   spin_lock(&man->bdev->lru_lock);
+   usage = man->usage;
+   spin_unlock(&man->bdev->lru_lock);
+   return usage;
+}
+EXPORT_SYMBOL(ttm_resource_manager_usage);
+
 /**
  * ttm_resource_manager_debug
  *
@@ -238,6 +267,7 @@ void ttm_resource_manager_debug(struct ttm_resource_manager 
*man,
drm_printf(p, "  use_type: %d\n", man->use_type);
drm_printf(p, "  use_tt: %d\n", man->use_tt);
drm_printf(p, "  size: %llu\n", man->size);
+   drm_printf(p, "  usage: %llu\n", ttm_resource_manager_usage(man));
if (man->func->debug)
man->func->debug(man, p);
 }
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index 69eea9d6399b..5516d6340aa7 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -27,6 +27,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -130,10 +131,15 @@ struct ttm_resource_manager {
struct dma_fence *move;
 
/*
-* Protected by the global->lru_lock.
+* Protected by the bdev->lru_lock.
 */
-
struct list_head lru[TTM_MAX_BO_PRIORITY];
+
+   /**
+* @usage: How much of the resources are used, protected by the
+* bdev->lru_lock.
+*/
+   uint64_t usage;
 };
 
 /**
@@ -283,6 +289,7 @@ void ttm_resource_manager_init(struct ttm_resource_manager 
*man,
 int ttm_resource_manager_evict_all(struct ttm_device *bdev,
   struct ttm_resource_manager *man);
 
+uint64_t ttm_resource_manager_usage(struct ttm_resource_manager *man);
 void ttm_resource_manager_debug(struct ttm_resource_manager *man,
struct drm_printer *p);
 
-- 
2.25.1

[PATCH 2/9] drm/ttm: move the LRU into resource handling v3

[Christian König]

This way we finally fix the problem that new resource are
not immediately evict-able after allocation.

That has caused numerous problems including OOM on GDS handling
and not being able to use TTM as general resource manager.

v2: stop assuming in ttm_resource_fini that res->bo is still valid.
v3: cleanup kerneldoc, add more lockdep annotation

Signed-off-by: Christian König 
Tested-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |   8 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c |   2 +-
 drivers/gpu/drm/ttm/ttm_bo.c| 115 ++
 drivers/gpu/drm/ttm/ttm_bo_util.c   |   1 -
 drivers/gpu/drm/ttm/ttm_device.c|  64 ++---
 drivers/gpu/drm/ttm/ttm_resource.c  | 122 +++-
 include/drm/ttm/ttm_bo_api.h|  16 
 include/drm/ttm/ttm_bo_driver.h |  29 +-
 include/drm/ttm/ttm_resource.h  |  35 +++
 9 files changed, 197 insertions(+), 195 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index b37fc7d7d2c7..f2ce5a0defd9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -683,12 +683,12 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device 
*adev,
 
if (vm->bulk_moveable) {
spin_lock(&adev->mman.bdev.lru_lock);
-   ttm_bo_bulk_move_lru_tail(&vm->lru_bulk_move);
+   ttm_lru_bulk_move_tail(&vm->lru_bulk_move);
spin_unlock(&adev->mman.bdev.lru_lock);
return;
}
 
-   memset(&vm->lru_bulk_move, 0, sizeof(vm->lru_bulk_move));
+   ttm_lru_bulk_move_init(&vm->lru_bulk_move);
 
spin_lock(&adev->mman.bdev.lru_lock);
list_for_each_entry(bo_base, &vm->idle, vm_status) {
@@ -698,11 +698,9 @@ void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
if (!bo->parent)
continue;
 
-   ttm_bo_move_to_lru_tail(&bo->tbo, bo->tbo.resource,
-   &vm->lru_bulk_move);
+   ttm_bo_move_to_lru_tail(&bo->tbo, &vm->lru_bulk_move);
if (shadow)
ttm_bo_move_to_lru_tail(&shadow->tbo,
-   shadow->tbo.resource,
&vm->lru_bulk_move);
}
spin_unlock(&adev->mman.bdev.lru_lock);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index de3fe79b665a..582e8dc9bc8c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -849,7 +849,7 @@ void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj)
bo->priority = I915_TTM_PRIO_NO_PAGES;
}
 
-   ttm_bo_move_to_lru_tail(bo, bo->resource, NULL);
+   ttm_bo_move_to_lru_tail(bo, NULL);
spin_unlock(&bo->bdev->lru_lock);
 }
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index db3dc7ef5382..cb0fa932d495 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -69,108 +69,16 @@ static void ttm_bo_mem_space_debug(struct 
ttm_buffer_object *bo,
}
 }
 
-static inline void ttm_bo_move_to_pinned(struct ttm_buffer_object *bo)
-{
-   struct ttm_device *bdev = bo->bdev;
-
-   list_move_tail(&bo->lru, &bdev->pinned);
-
-   if (bdev->funcs->del_from_lru_notify)
-   bdev->funcs->del_from_lru_notify(bo);
-}
-
-static inline void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
-{
-   struct ttm_device *bdev = bo->bdev;
-
-   list_del_init(&bo->lru);
-
-   if (bdev->funcs->del_from_lru_notify)
-   bdev->funcs->del_from_lru_notify(bo);
-}
-
-static void ttm_bo_bulk_move_set_pos(struct ttm_lru_bulk_move_pos *pos,
-struct ttm_buffer_object *bo)
-{
-   if (!pos->first)
-   pos->first = bo;
-   pos->last = bo;
-}
-
 void ttm_bo_move_to_lru_tail(struct ttm_buffer_object *bo,
-struct ttm_resource *mem,
 struct ttm_lru_bulk_move *bulk)
 {
-   struct ttm_device *bdev = bo->bdev;
-   struct ttm_resource_manager *man;
-
-   if (!bo->deleted)
-   dma_resv_assert_held(bo->base.resv);
-
-   if (bo->pin_count) {
-   ttm_bo_move_to_pinned(bo);
-   return;
-   }
-
-   if (!mem)
-   return;
-
-   man = ttm_manager_type(bdev, mem->mem_type);
-   list_move_tail(&bo->lru, &man->lru[bo->priority]);
-
-   if (bdev->funcs->del_from_lru_notify)
-   bdev->funcs->del_from_lru_notify(bo);
-
-   if (bulk && !bo->pin_count) {
-   switch (bo->resource->mem_type) {
-   case TTM_PL_TT:
-   ttm_bo_bulk_move_set_pos(&bulk->tt[bo->priority], bo);
-   break;
+   dma_resv_

[PATCH 4/9] drm/radeon: remove resource accounting

[Christian König]

Use the one provided by TTM instead.

Signed-off-by: Christian König 
Tested-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/radeon/radeon.h|  2 --
 drivers/gpu/drm/radeon/radeon_kms.c|  7 --
 drivers/gpu/drm/radeon/radeon_object.c | 30 +++---
 drivers/gpu/drm/radeon/radeon_object.h |  1 -
 drivers/gpu/drm/radeon/radeon_ttm.c| 18 ++--
 5 files changed, 10 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 895776c421d4..08f83bf2c330 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2462,8 +2462,6 @@ struct radeon_device {
struct radeon_vm_managervm_manager;
struct mutexgpu_clock_mutex;
/* memory stats */
-   atomic64_t  vram_usage;
-   atomic64_t  gtt_usage;
atomic64_t  num_bytes_moved;
atomic_tgpu_reset_counter;
/* ACPI interface */
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 11ad210919c8..965161b8565b 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -241,6 +241,7 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
struct drm_radeon_info *info = data;
struct radeon_mode_info *minfo = &rdev->mode_info;
uint32_t *value, value_tmp, *value_ptr, value_size;
+   struct ttm_resource_manager *man;
uint64_t value64;
struct drm_crtc *crtc;
int i, found;
@@ -550,12 +551,14 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
case RADEON_INFO_VRAM_USAGE:
value = (uint32_t*)&value64;
value_size = sizeof(uint64_t);
-   value64 = atomic64_read(&rdev->vram_usage);
+   man = ttm_manager_type(&rdev->mman.bdev, TTM_PL_VRAM);
+   value64 = ttm_resource_manager_usage(man);
break;
case RADEON_INFO_GTT_USAGE:
value = (uint32_t*)&value64;
value_size = sizeof(uint64_t);
-   value64 = atomic64_read(&rdev->gtt_usage);
+   man = ttm_manager_type(&rdev->mman.bdev, TTM_PL_TT);
+   value64 = ttm_resource_manager_usage(man);
break;
case RADEON_INFO_ACTIVE_CU_COUNT:
if (rdev->family >= CHIP_BONAIRE)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 56ede9d63b12..c9bbed2a25ad 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -49,27 +49,6 @@ static void radeon_bo_clear_surface_reg(struct radeon_bo 
*bo);
  * function are calling it.
  */
 
-static void radeon_update_memory_usage(struct ttm_buffer_object *bo,
-  unsigned int mem_type, int sign)
-{
-   struct radeon_device *rdev = radeon_get_rdev(bo->bdev);
-
-   switch (mem_type) {
-   case TTM_PL_TT:
-   if (sign > 0)
-   atomic64_add(bo->base.size, &rdev->gtt_usage);
-   else
-   atomic64_sub(bo->base.size, &rdev->gtt_usage);
-   break;
-   case TTM_PL_VRAM:
-   if (sign > 0)
-   atomic64_add(bo->base.size, &rdev->vram_usage);
-   else
-   atomic64_sub(bo->base.size, &rdev->vram_usage);
-   break;
-   }
-}
-
 static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo)
 {
struct radeon_bo *bo;
@@ -434,7 +413,9 @@ void radeon_bo_fini(struct radeon_device *rdev)
 static u64 radeon_bo_get_threshold_for_moves(struct radeon_device *rdev)
 {
u64 real_vram_size = rdev->mc.real_vram_size;
-   u64 vram_usage = atomic64_read(&rdev->vram_usage);
+   struct ttm_resource_manager *man =
+   ttm_manager_type(&rdev->mman.bdev, TTM_PL_VRAM);
+   u64 vram_usage = ttm_resource_manager_usage(man);
 
/* This function is based on the current VRAM usage.
 *
@@ -725,15 +706,10 @@ int radeon_bo_check_tiling(struct radeon_bo *bo, bool 
has_moved,
 }
 
 void radeon_bo_move_notify(struct ttm_buffer_object *bo,
-  unsigned int old_type,
   struct ttm_resource *new_mem)
 {
struct radeon_bo *rbo;
 
-   radeon_update_memory_usage(bo, old_type, -1);
-   if (new_mem)
-   radeon_update_memory_usage(bo, new_mem->mem_type, 1);
-
if (!radeon_ttm_bo_is_radeon_bo(bo))
return;
 
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index 1afc7992ef91..0b64e202577b 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -161,7 +161,6 @@ extern void radeon_bo_get_ti

[PATCH 5/9] drm/amdgpu: remove GTT accounting

[Christian König]

This is provided by TTM now.

Also switch man->size to bytes instead of pages and fix the double
printing of size and usage in debugfs.

Signed-off-by: Christian König 
Tested-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 49 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  8 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  2 -
 3 files changed, 15 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index e0c7fbe01d93..3bcd27ae379d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -60,7 +60,7 @@ static ssize_t amdgpu_mem_info_gtt_total_show(struct device 
*dev,
struct ttm_resource_manager *man;
 
man = ttm_manager_type(&adev->mman.bdev, TTM_PL_TT);
-   return sysfs_emit(buf, "%llu\n", man->size * PAGE_SIZE);
+   return sysfs_emit(buf, "%llu\n", man->size);
 }
 
 /**
@@ -77,8 +77,9 @@ static ssize_t amdgpu_mem_info_gtt_used_show(struct device 
*dev,
 {
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(ddev);
+   struct ttm_resource_manager *man = &adev->mman.gtt_mgr.manager;
 
-   return sysfs_emit(buf, "%llu\n", 
amdgpu_gtt_mgr_usage(&adev->mman.gtt_mgr));
+   return sysfs_emit(buf, "%llu\n", ttm_resource_manager_usage(man));
 }
 
 static DEVICE_ATTR(mem_info_gtt_total, S_IRUGO,
@@ -130,20 +131,17 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager 
*man,
struct amdgpu_gtt_node *node;
int r;
 
-   if (!(place->flags & TTM_PL_FLAG_TEMPORARY) &&
-   atomic64_add_return(num_pages, &mgr->used) >  man->size) {
-   atomic64_sub(num_pages, &mgr->used);
-   return -ENOSPC;
-   }
-
node = kzalloc(struct_size(node, base.mm_nodes, 1), GFP_KERNEL);
-   if (!node) {
-   r = -ENOMEM;
-   goto err_out;
-   }
+   if (!node)
+   return -ENOMEM;
 
node->tbo = tbo;
ttm_resource_init(tbo, place, &node->base.base);
+   if (!(place->flags & TTM_PL_FLAG_TEMPORARY) &&
+   ttm_resource_manager_usage(man) > man->size) {
+   r = -ENOSPC;
+   goto err_free;
+   }
 
if (place->lpfn) {
spin_lock(&mgr->lock);
@@ -169,11 +167,6 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager 
*man,
 err_free:
ttm_resource_fini(man, &node->base.base);
kfree(node);
-
-err_out:
-   if (!(place->flags & TTM_PL_FLAG_TEMPORARY))
-   atomic64_sub(num_pages, &mgr->used);
-
return r;
 }
 
@@ -196,25 +189,10 @@ static void amdgpu_gtt_mgr_del(struct 
ttm_resource_manager *man,
drm_mm_remove_node(&node->base.mm_nodes[0]);
spin_unlock(&mgr->lock);
 
-   if (!(res->placement & TTM_PL_FLAG_TEMPORARY))
-   atomic64_sub(res->num_pages, &mgr->used);
-
ttm_resource_fini(man, res);
kfree(node);
 }
 
-/**
- * amdgpu_gtt_mgr_usage - return usage of GTT domain
- *
- * @mgr: amdgpu_gtt_mgr pointer
- *
- * Return how many bytes are used in the GTT domain
- */
-uint64_t amdgpu_gtt_mgr_usage(struct amdgpu_gtt_mgr *mgr)
-{
-   return atomic64_read(&mgr->used) * PAGE_SIZE;
-}
-
 /**
  * amdgpu_gtt_mgr_recover - re-init gart
  *
@@ -260,9 +238,6 @@ static void amdgpu_gtt_mgr_debug(struct 
ttm_resource_manager *man,
spin_lock(&mgr->lock);
drm_mm_print(&mgr->mm, printer);
spin_unlock(&mgr->lock);
-
-   drm_printf(printer, "man size:%llu pages,  gtt used:%llu pages\n",
-  man->size, atomic64_read(&mgr->used));
 }
 
 static const struct ttm_resource_manager_func amdgpu_gtt_mgr_func = {
@@ -288,14 +263,12 @@ int amdgpu_gtt_mgr_init(struct amdgpu_device *adev, 
uint64_t gtt_size)
man->use_tt = true;
man->func = &amdgpu_gtt_mgr_func;
 
-   ttm_resource_manager_init(man, &adev->mman.bdev,
- gtt_size >> PAGE_SHIFT);
+   ttm_resource_manager_init(man, &adev->mman.bdev, gtt_size);
 
start = AMDGPU_GTT_MAX_TRANSFER_SIZE * AMDGPU_GTT_NUM_TRANSFER_WINDOWS;
size = (adev->gmc.gart_size >> PAGE_SHIFT) - start;
drm_mm_init(&mgr->mm, start, size);
spin_lock_init(&mgr->lock);
-   atomic64_set(&mgr->used, 0);
 
ttm_set_driver_manager(&adev->mman.bdev, TTM_PL_TT, &mgr->manager);
ttm_resource_manager_set_used(man, true);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 1ebb91db2274..9ff4aced5da7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -684,7 +684,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
ui64 = amdgpu_vram_mgr_vis_usage(&adev->mman.vram_mgr);
return copy_to_user(out, &ui64, min(s

[PATCH 6/9] drm/amdgpu: remove VRAM accounting

[Christian König]

This is provided by TTM now.

Also switch man->size to bytes instead of pages and fix the double
printing of size and usage in debugfs.

Signed-off-by: Christian König 
Tested-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c  |  6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h  |  2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |  6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 58 +++-
 6 files changed, 31 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index e8440d306496..025748e9c772 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -314,7 +314,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct 
amdgpu_device *adev,
}
 
total_vram = adev->gmc.real_vram_size - 
atomic64_read(&adev->vram_pin_size);
-   used_vram = amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
+   used_vram = ttm_resource_manager_usage(&adev->mman.vram_mgr.manager);
free_vram = used_vram >= total_vram ? 0 : total_vram - used_vram;
 
spin_lock(&adev->mm_stats.lock);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 9ff4aced5da7..0beab961b18b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -678,7 +678,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
ui64 = atomic64_read(&adev->num_vram_cpu_page_faults);
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_VRAM_USAGE:
-   ui64 = amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
+   ui64 = ttm_resource_manager_usage(&adev->mman.vram_mgr.manager);
return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
case AMDGPU_INFO_VIS_VRAM_USAGE:
ui64 = amdgpu_vram_mgr_vis_usage(&adev->mman.vram_mgr);
@@ -717,6 +717,8 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
struct drm_amdgpu_memory_info mem;
struct ttm_resource_manager *gtt_man =
&adev->mman.gtt_mgr.manager;
+   struct ttm_resource_manager *vram_man =
+   &adev->mman.vram_mgr.manager;
 
memset(&mem, 0, sizeof(mem));
mem.vram.total_heap_size = adev->gmc.real_vram_size;
@@ -724,7 +726,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
atomic64_read(&adev->vram_pin_size) -
AMDGPU_VM_RESERVED_VRAM;
mem.vram.heap_usage =
-   amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
+   ttm_resource_manager_usage(vram_man);
mem.vram.max_allocation = mem.vram.usable_heap_size * 3 / 4;
 
mem.cpu_accessible_vram.total_heap_size =
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d178fbec7048..5859ed0552a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1884,7 +1884,7 @@ void amdgpu_ttm_set_buffer_funcs_status(struct 
amdgpu_device *adev, bool enable)
size = adev->gmc.real_vram_size;
else
size = adev->gmc.visible_vram_size;
-   man->size = size >> PAGE_SHIFT;
+   man->size = size;
adev->mman.buffer_funcs_enabled = enable;
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 120b69ec9885..cbee84a77331 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -44,7 +44,6 @@ struct amdgpu_vram_mgr {
spinlock_t lock;
struct list_head reservations_pending;
struct list_head reserved_pages;
-   atomic64_t usage;
atomic64_t vis_usage;
 };
 
@@ -127,7 +126,6 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
 void amdgpu_vram_mgr_free_sgt(struct device *dev,
  enum dma_data_direction dir,
  struct sg_table *sgt);
-uint64_t amdgpu_vram_mgr_usage(struct amdgpu_vram_mgr *mgr);
 uint64_t amdgpu_vram_mgr_vis_usage(struct amdgpu_vram_mgr *mgr);
 int amdgpu_vram_mgr_reserve_range(struct amdgpu_vram_mgr *mgr,
  uint64_t start, uint64_t size);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index 07bc0f504713..3a25dd220786 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
@@ -575,8 +575,10 @@ static int amdgpu_virt_write_vf2pf_data(struct 
amdgpu_device *adev)
vf2pf_info->driver_c

[PATCH 7/9] drm/amdgpu: drop amdgpu_gtt_node v2

[Christian König]

We have the BO pointer in the base structure now as well.

v2: add lockdep and kerneldoc

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 
Tested-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 49 -
 include/drm/ttm/ttm_resource.h  |  8 
 2 files changed, 26 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 3bcd27ae379d..68494b959116 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -26,23 +26,12 @@
 
 #include "amdgpu.h"
 
-struct amdgpu_gtt_node {
-   struct ttm_buffer_object *tbo;
-   struct ttm_range_mgr_node base;
-};
-
 static inline struct amdgpu_gtt_mgr *
 to_gtt_mgr(struct ttm_resource_manager *man)
 {
return container_of(man, struct amdgpu_gtt_mgr, manager);
 }
 
-static inline struct amdgpu_gtt_node *
-to_amdgpu_gtt_node(struct ttm_resource *res)
-{
-   return container_of(res, struct amdgpu_gtt_node, base.base);
-}
-
 /**
  * DOC: mem_info_gtt_total
  *
@@ -106,9 +95,9 @@ const struct attribute_group amdgpu_gtt_mgr_attr_group = {
  */
 bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_resource *res)
 {
-   struct amdgpu_gtt_node *node = to_amdgpu_gtt_node(res);
+   struct ttm_range_mgr_node *node = to_ttm_range_mgr_node(res);
 
-   return drm_mm_node_allocated(&node->base.mm_nodes[0]);
+   return drm_mm_node_allocated(&node->mm_nodes[0]);
 }
 
 /**
@@ -128,15 +117,14 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager 
*man,
 {
struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
uint32_t num_pages = PFN_UP(tbo->base.size);
-   struct amdgpu_gtt_node *node;
+   struct ttm_range_mgr_node *node;
int r;
 
-   node = kzalloc(struct_size(node, base.mm_nodes, 1), GFP_KERNEL);
+   node = kzalloc(struct_size(node, mm_nodes, 1), GFP_KERNEL);
if (!node)
return -ENOMEM;
 
-   node->tbo = tbo;
-   ttm_resource_init(tbo, place, &node->base.base);
+   ttm_resource_init(tbo, place, &node->base);
if (!(place->flags & TTM_PL_FLAG_TEMPORARY) &&
ttm_resource_manager_usage(man) > man->size) {
r = -ENOSPC;
@@ -145,8 +133,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager 
*man,
 
if (place->lpfn) {
spin_lock(&mgr->lock);
-   r = drm_mm_insert_node_in_range(&mgr->mm,
-   &node->base.mm_nodes[0],
+   r = drm_mm_insert_node_in_range(&mgr->mm, &node->mm_nodes[0],
num_pages, tbo->page_alignment,
0, place->fpfn, place->lpfn,
DRM_MM_INSERT_BEST);
@@ -154,18 +141,18 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager 
*man,
if (unlikely(r))
goto err_free;
 
-   node->base.base.start = node->base.mm_nodes[0].start;
+   node->base.start = node->mm_nodes[0].start;
} else {
-   node->base.mm_nodes[0].start = 0;
-   node->base.mm_nodes[0].size = node->base.base.num_pages;
-   node->base.base.start = AMDGPU_BO_INVALID_OFFSET;
+   node->mm_nodes[0].start = 0;
+   node->mm_nodes[0].size = node->base.num_pages;
+   node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
 
-   *res = &node->base.base;
+   *res = &node->base;
return 0;
 
 err_free:
-   ttm_resource_fini(man, &node->base.base);
+   ttm_resource_fini(man, &node->base);
kfree(node);
return r;
 }
@@ -181,12 +168,12 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager 
*man,
 static void amdgpu_gtt_mgr_del(struct ttm_resource_manager *man,
   struct ttm_resource *res)
 {
-   struct amdgpu_gtt_node *node = to_amdgpu_gtt_node(res);
+   struct ttm_range_mgr_node *node = to_ttm_range_mgr_node(res);
struct amdgpu_gtt_mgr *mgr = to_gtt_mgr(man);
 
spin_lock(&mgr->lock);
-   if (drm_mm_node_allocated(&node->base.mm_nodes[0]))
-   drm_mm_remove_node(&node->base.mm_nodes[0]);
+   if (drm_mm_node_allocated(&node->mm_nodes[0]))
+   drm_mm_remove_node(&node->mm_nodes[0]);
spin_unlock(&mgr->lock);
 
ttm_resource_fini(man, res);
@@ -202,7 +189,7 @@ static void amdgpu_gtt_mgr_del(struct ttm_resource_manager 
*man,
  */
 int amdgpu_gtt_mgr_recover(struct amdgpu_gtt_mgr *mgr)
 {
-   struct amdgpu_gtt_node *node;
+   struct ttm_range_mgr_node *node;
struct drm_mm_node *mm_node;
struct amdgpu_device *adev;
int r = 0;
@@ -210,8 +197,8 @@ int amdgpu_gtt_mgr_recover(struct amdgpu_gtt_mgr *mgr)
adev = container_of(mgr, typeof(*adev), mman.gtt_mgr);
  

[PATCH 8/9] drm/ttm: allow bulk moves for all domains

[Christian König]

Not just TT and VRAM.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 
Tested-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/ttm/ttm_resource.c | 52 +-
 include/drm/ttm/ttm_device.h   |  2 --
 include/drm/ttm/ttm_resource.h |  4 +--
 3 files changed, 17 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index e3301f6277ba..5e732a509b4b 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -51,38 +51,24 @@ EXPORT_SYMBOL(ttm_lru_bulk_move_init);
  */
 void ttm_lru_bulk_move_tail(struct ttm_lru_bulk_move *bulk)
 {
-   unsigned i;
-
-   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
-   struct ttm_lru_bulk_move_pos *pos = &bulk->tt[i];
-   struct ttm_resource_manager *man;
+   unsigned i, j;
 
-   if (!pos->first)
-   continue;
+   for (i = 0; i < TTM_NUM_MEM_TYPES; ++i) {
+   for (j = 0; j < TTM_MAX_BO_PRIORITY; ++j) {
+   struct ttm_lru_bulk_move_pos *pos = &bulk->pos[i][j];
+   struct ttm_resource_manager *man;
 
-   lockdep_assert_held(&pos->first->bo->bdev->lru_lock);
-   dma_resv_assert_held(pos->first->bo->base.resv);
-   dma_resv_assert_held(pos->last->bo->base.resv);
+   if (!pos->first)
+   continue;
 
-   man = ttm_manager_type(pos->first->bo->bdev, TTM_PL_TT);
-   list_bulk_move_tail(&man->lru[i], &pos->first->lru,
-   &pos->last->lru);
-   }
-
-   for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
-   struct ttm_lru_bulk_move_pos *pos = &bulk->vram[i];
-   struct ttm_resource_manager *man;
+   lockdep_assert_held(&pos->first->bo->bdev->lru_lock);
+   dma_resv_assert_held(pos->first->bo->base.resv);
+   dma_resv_assert_held(pos->last->bo->base.resv);
 
-   if (!pos->first)
-   continue;
-
-   lockdep_assert_held(&pos->first->bo->bdev->lru_lock);
-   dma_resv_assert_held(pos->first->bo->base.resv);
-   dma_resv_assert_held(pos->last->bo->base.resv);
-
-   man = ttm_manager_type(pos->first->bo->bdev, TTM_PL_VRAM);
-   list_bulk_move_tail(&man->lru[i], &pos->first->lru,
-   &pos->last->lru);
+   man = ttm_manager_type(pos->first->bo->bdev, i);
+   list_bulk_move_tail(&man->lru[j], &pos->first->lru,
+   &pos->last->lru);
+   }
}
 }
 EXPORT_SYMBOL(ttm_lru_bulk_move_tail);
@@ -122,15 +108,7 @@ void ttm_resource_move_to_lru_tail(struct ttm_resource 
*res,
if (!bulk)
return;
 
-   switch (res->mem_type) {
-   case TTM_PL_TT:
-   ttm_lru_bulk_move_set_pos(&bulk->tt[bo->priority], res);
-   break;
-
-   case TTM_PL_VRAM:
-   ttm_lru_bulk_move_set_pos(&bulk->vram[bo->priority], res);
-   break;
-   }
+   ttm_lru_bulk_move_set_pos(&bulk->pos[res->mem_type][bo->priority], res);
 }
 
 /**
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 0a4ddec78d8f..425150f35fbe 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -30,8 +30,6 @@
 #include 
 #include 
 
-#define TTM_NUM_MEM_TYPES 8
-
 struct ttm_device;
 struct ttm_placement;
 struct ttm_buffer_object;
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index cc452a7aa016..5f93a16acfd6 100644
--- a/include/drm/ttm/ttm_resource.h
+++ b/include/drm/ttm/ttm_resource.h
@@ -37,6 +37,7 @@
 #include 
 
 #define TTM_MAX_BO_PRIORITY4U
+#define TTM_NUM_MEM_TYPES 8
 
 struct ttm_device;
 struct ttm_resource_manager;
@@ -217,8 +218,7 @@ struct ttm_lru_bulk_move_pos {
  * Helper structure for bulk moves on the LRU list.
  */
 struct ttm_lru_bulk_move {
-   struct ttm_lru_bulk_move_pos tt[TTM_MAX_BO_PRIORITY];
-   struct ttm_lru_bulk_move_pos vram[TTM_MAX_BO_PRIORITY];
+   struct ttm_lru_bulk_move_pos 
pos[TTM_NUM_MEM_TYPES][TTM_MAX_BO_PRIORITY];
 };
 
 /**
-- 
2.25.1

[PATCH 9/9] drm/ttm: rework bulk move handling v2

[Christian König]

Instead of providing the bulk move structure for each LRU update set
this as property of the BO. This should avoid costly bulk move rebuilds
with some games under RADV.

v2: some name polishing, add a few more kerneldoc words.
v3: add some lockdep

Signed-off-by: Christian König 
Tested-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  | 72 +++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h  |  3 -
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c |  2 +-
 drivers/gpu/drm/ttm/ttm_bo.c| 47 +++--
 drivers/gpu/drm/ttm/ttm_resource.c  | 87 ++---
 include/drm/ttm/ttm_bo_api.h| 16 ++---
 include/drm/ttm/ttm_bo_driver.h |  2 +-
 include/drm/ttm/ttm_device.h|  9 ---
 include/drm/ttm/ttm_resource.h  |  9 ++-
 10 files changed, 128 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 5859ed0552a4..57ac118fc266 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1498,7 +1498,6 @@ static struct ttm_device_funcs amdgpu_bo_driver = {
.io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
.io_mem_pfn = amdgpu_ttm_io_mem_pfn,
.access_memory = &amdgpu_ttm_access_memory,
-   .del_from_lru_notify = &amdgpu_vm_del_from_lru_notify
 };
 
 /*
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index f2ce5a0defd9..28f5e8b21a99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -375,7 +375,7 @@ static void amdgpu_vm_bo_base_init(struct amdgpu_vm_bo_base 
*base,
if (bo->tbo.base.resv != vm->root.bo->tbo.base.resv)
return;
 
-   vm->bulk_moveable = false;
+   ttm_bo_set_bulk_move(&bo->tbo, &vm->lru_bulk_move);
if (bo->tbo.type == ttm_bo_type_kernel && bo->parent)
amdgpu_vm_bo_relocated(base);
else
@@ -637,36 +637,6 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
list_add(&entry->tv.head, validated);
 }
 
-/**
- * amdgpu_vm_del_from_lru_notify - update bulk_moveable flag
- *
- * @bo: BO which was removed from the LRU
- *
- * Make sure the bulk_moveable flag is updated when a BO is removed from the
- * LRU.
- */
-void amdgpu_vm_del_from_lru_notify(struct ttm_buffer_object *bo)
-{
-   struct amdgpu_bo *abo;
-   struct amdgpu_vm_bo_base *bo_base;
-
-   if (!amdgpu_bo_is_amdgpu_bo(bo))
-   return;
-
-   if (bo->pin_count)
-   return;
-
-   abo = ttm_to_amdgpu_bo(bo);
-   if (!abo->parent)
-   return;
-   for (bo_base = abo->vm_bo; bo_base; bo_base = bo_base->next) {
-   struct amdgpu_vm *vm = bo_base->vm;
-
-   if (abo->tbo.base.resv == vm->root.bo->tbo.base.resv)
-   vm->bulk_moveable = false;
-   }
-
-}
 /**
  * amdgpu_vm_move_to_lru_tail - move all BOs to the end of LRU
  *
@@ -679,33 +649,9 @@ void amdgpu_vm_del_from_lru_notify(struct 
ttm_buffer_object *bo)
 void amdgpu_vm_move_to_lru_tail(struct amdgpu_device *adev,
struct amdgpu_vm *vm)
 {
-   struct amdgpu_vm_bo_base *bo_base;
-
-   if (vm->bulk_moveable) {
-   spin_lock(&adev->mman.bdev.lru_lock);
-   ttm_lru_bulk_move_tail(&vm->lru_bulk_move);
-   spin_unlock(&adev->mman.bdev.lru_lock);
-   return;
-   }
-
-   ttm_lru_bulk_move_init(&vm->lru_bulk_move);
-
spin_lock(&adev->mman.bdev.lru_lock);
-   list_for_each_entry(bo_base, &vm->idle, vm_status) {
-   struct amdgpu_bo *bo = bo_base->bo;
-   struct amdgpu_bo *shadow = amdgpu_bo_shadowed(bo);
-
-   if (!bo->parent)
-   continue;
-
-   ttm_bo_move_to_lru_tail(&bo->tbo, &vm->lru_bulk_move);
-   if (shadow)
-   ttm_bo_move_to_lru_tail(&shadow->tbo,
-   &vm->lru_bulk_move);
-   }
+   ttm_lru_bulk_move_tail(&vm->lru_bulk_move);
spin_unlock(&adev->mman.bdev.lru_lock);
-
-   vm->bulk_moveable = true;
 }
 
 /**
@@ -728,8 +674,6 @@ int amdgpu_vm_validate_pt_bos(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
struct amdgpu_vm_bo_base *bo_base, *tmp;
int r;
 
-   vm->bulk_moveable &= list_empty(&vm->evicted);
-
list_for_each_entry_safe(bo_base, tmp, &vm->evicted, vm_status) {
struct amdgpu_bo *bo = bo_base->bo;
struct amdgpu_bo *shadow = amdgpu_bo_shadowed(bo);
@@ -1047,10 +991,16 @@ static void amdgpu_vm_free_table(struct 
amdgpu_vm_bo_base *entry)
 
if (!entry->bo)
return;
+
shadow = amdgpu_bo_shadowed(entry->bo);
+   if (shadow) {
+   ttm_bo_set_bulk_move(&shadow->tbo, NULL);
+   

Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller

[Maxime Ripard]

On Fri, Feb 04, 2022 at 12:29:39AM +0800, Sui Jingfeng wrote:
> > > +static int lsdc_modeset = 1;
> > > +MODULE_PARM_DESC(modeset, "Enable/disable CMA-based KMS(1 = 
> > > enabled(default), 0 = disabled)");
> > > +module_param_named(modeset, lsdc_modeset, int, 0644);
> > > +
> > > +static int lsdc_cached_coherent = 1;
> > > +MODULE_PARM_DESC(cached_coherent, "uss cached coherent mapping(1 = 
> > > enabled(default), 0 = disabled)");
> > > +module_param_named(cached_coherent, lsdc_cached_coherent, int, 0644);
> > > +
> > > +static int lsdc_dirty_update = -1;
> > > +MODULE_PARM_DESC(dirty_update, "enable dirty update(1 = enabled, 0 = 
> > > disabled(default))");
> > > +module_param_named(dirty_update, lsdc_dirty_update, int, 0644);
> > > +
> > > +static int lsdc_use_vram_helper = -1;
> > > +MODULE_PARM_DESC(use_vram_helper, "use vram helper based solution(1 = 
> > > enabled, 0 = disabled(default))");
> > > +module_param_named(use_vram_helper, lsdc_use_vram_helper, int, 0644);
> > > +
> > > +static int lsdc_verbose = -1;
> > > +MODULE_PARM_DESC(verbose, "Enable/disable print some key information");
> > > +module_param_named(verbose, lsdc_verbose, int, 0644);
> >
> > It's not really clear to me why you need any of those parameters. Why
> > would a user want to use a non coherent mapping for example?
> > 
> Because we are Mips architecture. Paul Cercueil already explained it
> in his mmap GEM buffers cachedpatch  
> .
>  I drag part of it to here for
> convenient to reading:
> 
> /Traditionally, GEM buffers are mapped write-combine. Writes to the buffer
> are accelerated, and reads are slow. Application doing lotsof
> alpha-blending paint inside shadow buffers, which is then memcpy'dinto
> the final GEM buffer.///
> "non coherent mapping" is actually cached and it is for CMA helpers
> base driver, not for VRAM helper based driver. For Loongson CPU/SoCs.
> The cache coherency is maintained by hardware, therefore there no
> need to worry about coherency problems. This is true at least for
> ls3a3000, ls3a4000 and ls3a5000.
> 
> "non coherent" or "coherent" is not important here, the key point is
> that the backing memory of the framebuffer is cached with non coherent
> mapping, you don't need a shadow buffer layer when using X server's
> modesetting driver.
> 
> Read and write to the framebuffer in system memory is much faster than
> read and write to the framebuffer in the VRAM.
> 
> Why CMA helper based solution is faster than the VRAM based solution on Mips 
> platform?
> 
> Partly because of the CPU have L1, L2 and L3 cache, especially L3 cache
> is as large as 8MB, read and write from the cache is fast.
> 
> Another reason is as Paul Cercueil said, read from VRAM with write-combine
> cache mode is slow. it is just uncache read.
> Please note that we don't have a GPU here, we are just a display controller.
> 
> For the VRAM helper based driver case, the backing memory of the framebuffer
> is located at VRAM, When using X server's modesetting driver, we have to 
> enable
> the ShadowFB option, Uncache acceleration support(at the kernel size) should
> also be enabled. Otherwise the performance of graphic application is just 
> slow.
> 
> Beside write-combine cache mode have bugs on our platform, a kernel side
> developer have disabled it. Write-combine cache mode just boil down to 
> uncached
> now. See [1] and [2]
> 
> [1]https://lkml.org/lkml/2020/8/10/255
> [2]https://lkml.kernel.org/lkml/1617701112-14007-1-git-send-email-yangtie...@loongson.cn/T/
>
> This is the reason why we prefer CMA helper base solution with non coherent 
> mapping,
> simply because it is fast.
> 
> As far as I know, Loongson's CPU does not has the concept of write-combine,
> it only support three caching mode:  uncached, cached and uncache 
> acceleration.
> write-combine is implemented with uncache acceleration on Mips.

My point wasn't just about the VRAM vs CMA stuff, it was about why do
you need all those switches in the first place?

Take the verbose parameter for example: it's entirely redundant with the
already existing, documented, DRM logging infrastructure.

Then, you have "modeset", and I'm not sure why it's supposed to be
there, at all. This is a modesetting driver, why would I want to disable
modesetting entirely?

More fundamentally (and this extends to the CMA, caching and VRAM stuff
you explained above), why can't the driver pick the right decision all
the time and why would that be under the user control?

You were mentioning that you need to work-around MIPS memory management.
Then fine, just do that on MIPS, and don't it on the other architectures
that don't need it. There's no need for a knob.

Maxime


signature.asc
Description: PGP signature

[PATCH] fbcon: use min() to make code cleaner

[cgel . zte]

From: Changcheng Deng 

Use min() in order to make code cleaner.

Reported-by: Zeal Robot 
Signed-off-by: Changcheng Deng 
---
 drivers/video/fbdev/core/fbcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index f36829eeb5a9..61171159fee2 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -602,7 +602,7 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct 
fb_info *info,
save = kmalloc(array3_size(logo_lines, new_cols, 2),
   GFP_KERNEL);
if (save) {
-   int i = cols < new_cols ? cols : new_cols;
+   int i = min(cols, new_cols);
scr_memsetw(save, erase, array3_size(logo_lines, 
new_cols, 2));
r = q - step;
for (cnt = 0; cnt < logo_lines; cnt++, r += i)
-- 
2.25.1

Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller

[Maxime Ripard]

On Fri, Feb 04, 2022 at 12:04:19AM +0800, Sui Jingfeng wrote:
> > > +/* Get the simple EDID data from the device tree
> > > + * the length must be EDID_LENGTH, since it is simple.
> > > + *
> > > + * @np: device node contain edid data
> > > + * @edid_data: where the edid data to store to
> > > + */
> > > +static bool lsdc_get_edid_from_dtb(struct device_node *np,
> > > +unsigned char *edid_data)
> > > +{
> > > + int length;
> > > + const void *prop;
> > > +
> > > + if (np == NULL)
> > > + return false;
> > > +
> > > + prop = of_get_property(np, "edid", &length);
> > > + if (prop && (length == EDID_LENGTH)) {
> > > + memcpy(edid_data, prop, EDID_LENGTH);
> > > + return true;
> > > + }
> > > +
> > > + return false;
> > > +}
> >
> > You don't have a device tree binding for that driver, this is something
> > that is required. And it's not clear to me why you'd want EDID in the
> > DTB?
> 
> 1) It is left to the end user of this driver.
> 
> The downstream motherboard maker may use a dpi(XRGB888) or LVDS panel
> which don't have DDC support either, doing this way allow them put a
> EDID property into the dc device node in the DTS. Then the entire system 
> works.
> Note those panel usually support only one display mode.

I guess it depends on what we mean exactly by the user, but the DTB
usually isn't under the (end) user control. And the drm.edid_firmware is
here already to address exactly this issue.

On the other end, if the board has a static panel without any DDC lines,
then just put the timings in the device tree, there's no need for an
EDID blob.

> 2) That is for the display controller in ls2k1000 SoC.
> 
> Currently, the upstream kernel still don't have GPIO, PWM and I2C driver 
> support
> for LS2K1000 SoC.
> 
> How dose you read EDID from the monitor without a I2C driver?
> 
> without reading EDID the device tree support, the screen just black,
> the lsdc driver just stall. With reading EDID from device tree support
> we do not need a i2c driver to light up the monitor.
> 
> This make lsdc drm driver work on various ls2k1000 development board
> before I2C driver and GPIO driver and PWM backlight driver is upstream.
> 
> I have many local private dts with the bindings, those local change just can 
> not
> upstream at this time, below is an example.

The device tree is a platform description language. It's there to let
the OS know what the hardware is, but the state of hardware support in
the said OS isn't a parameter we have to take into account for a new
binding.

If you don't have any DDC support at the moment, use the firmware
mechanism above, or add fixed modes using drm_add_modes_noedid in the
driver, and leave the DT out of it. Once you'll gain support for the
EDID readout in the driver, then it'll just work and you won't need to
change the DT again.

> 3) Again, doing this way is for graphic environment bring up.
> 
> &lsdc {
> 
>     output-ports = <&dvo0 &dvo1>;
>     #address-cells = <1>;
>     #size-cells = <0>;
>     dvo0: dvo@0 {
>     reg = <0>;
> 
>     connector = "dpi-connector";
>     encoder = "none";
>     status = "ok";
> 
>     display-timings {
>         native-mode = <&mode_0_1024x600_60>;
> 
>         mode_0_1024x600_60: panel-timing@0 {
>             clock-frequency = <5120>;
>             hactive = <1024>;
>             vactive = <600>;
>             hsync-len = <4>;
>             hfront-porch = <160>;
>             hback-porch = <156>;
>             vfront-porch = <11>;
>             vback-porch = <23>;
>             vsync-len = <1>;
>         };
> 
>         mode_1_800x480_60: panel-timing@1 {
>             clock-frequency = <30066000>;
>             hactive = <800>;
>             vactive = <480>;
>             hfront-porch = <50>;
>             hback-porch = <70>;
>             hsync-len = <50>;
>             vback-porch = <0>;
>             vfront-porch = <0>;
>             vsync-len = <50>;
>         };
>     };
>     };
> 
>     dvo1: dvo@1 {
>     reg = <1>;
> 
>     connector = "hdmi-connector";
>     type = "a";
>     encoder = "sil9022";
> 
>     edid = [ 00 ff ff ff ff ff ff 00 1e 6d 54 5b 0b cc 04 00
>          02 1c 01 03 6c 30 1b 78 ea 31 35 a5 55 4e a1 26
>          0c 50 54 a5 4b 00 71 4f 81 80 95 00 b3 00 a9 c0
>          81 00 81 c0 90 40 02 3a 80 18 71 38 2d 40 58 2c
>          45 00 e0 0e 11 00 00 1e 00 00 00 fd 00 38 4b 1e
>          53 0f 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4c
>          47 20 46 55 4c 4c 20 48 44 0a 20 20 00 00 00 ff
>          00 38 30 32 4e 54 43 5a 39 38 33 37 39 0a 00 35 ];
> 
>     status = "ok";
>     };
> };

Yeah, this needs to be documented with a YAML schema

Maxime


signature.asc
Description: PGP signature

[PATCH v5 0/5] Add GPU for RK356x SoCs

[Michael Riesch]

Hi all,

This series seems to be abandoned so I would like to pick it up in order to
bring the GPU support for the RK356x mainline.

The series (in conjunction with the VOP2/HDMI TX patches v4 [0]) has been tested
successfully on a RK3568 EVB1 with weston and glmark2-es2-wayland.

It should be noted that on the RK3568 EVB1 the supply of the GPU power domain 
needs
to be set to "always-on" in the device tree. There is an ongoing discussion to
provide a clean solution [1], in the meantime one has to apply a hack.

Looking forward to your comments!

Best regards,
Michael

v5:
- address Rob's comments, describe clocks in SoC specific region
- move gpu_opp_table so that nodes without a reg are sorted alphabetically
- add GPU support to the RK3568 EVB1

v4: see 
https://lore.kernel.org/linux-rockchip/20211126151729.1026566-1-knaerz...@gmail.com/
v3: see 
https://lore.kernel.org/linux-rockchip/20210805025948.10900-1-ezequ...@collabora.com/
v2: see 
https://lore.kernel.org/linux-rockchip/20210730164515.83044-1-ezequ...@collabora.com/

[0] 
https://lore.kernel.org/linux-rockchip/20220126145549.617165-1-s.ha...@pengutronix.de/
[1] 
https://lore.kernel.org/linux-rockchip/20211217130919.3035788-1-s.ha...@pengutronix.de/

Alex Bee (2):
  dt-bindings: gpu: mali-bifrost: describe clocks for the rk356x gpu
  arm64: dts: rockchip: add cooling map and trip points for gpu to
rk356x

Ezequiel Garcia (2):
  arm64: dts: rockchip: add gpu node to rk356x
  arm64: dts: rockchip: enable the gpu on quartz64-a

Michael Riesch (1):
  arm64: dts: rockchip: enable the gpu on rk3568-evb1-v10

 .../bindings/gpu/arm,mali-bifrost.yaml| 15 
 .../boot/dts/rockchip/rk3566-quartz64-a.dts   |  5 ++
 .../boot/dts/rockchip/rk3568-evb1-v10.dts | 11 +++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi  | 76 +++
 4 files changed, 107 insertions(+)

-- 
2.30.2

[PATCH v5 3/5] arm64: dts: rockchip: add cooling map and trip points for gpu to rk356x

[Michael Riesch]

From: Alex Bee 

RK356x SoCs have a second thermal sensor for the GPU. This adds the
cooling map and trip points for it to make use of its contribution as
a cooling device.

Signed-off-by: Alex Bee 
Signed-off-by: Michael Riesch 
---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 27 
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi 
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 47484305b7a4..2334fed4620f 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -1093,6 +1093,33 @@ gpu_thermal: gpu-thermal {
polling-delay = <1000>; /* milliseconds */
 
thermal-sensors = <&tsadc 1>;
+
+   trips {
+   gpu_threshold: gpu-threshold {
+   temperature = <7>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+   gpu_target: gpu-target {
+   temperature = <75000>;
+   hysteresis = <2000>;
+   type = "passive";
+   };
+   gpu_crit: gpu-crit {
+   temperature = <95000>;
+   hysteresis = <2000>;
+   type = "critical";
+   };
+   };
+
+   cooling-maps {
+   map0 {
+   trip = <&gpu_target>;
+   cooling-device =
+   <&gpu THERMAL_NO_LIMIT 
THERMAL_NO_LIMIT>;
+   };
+   };
+
};
};
 
-- 
2.30.2

[PATCH v5 1/5] dt-bindings: gpu: mali-bifrost: describe clocks for the rk356x gpu

[Michael Riesch]

From: Alex Bee 

The Bifrost GPU in Rockchip RK356x SoCs has a core and a bus clock.
Reflect this in the SoC specific part of the binding.

Signed-off-by: Alex Bee 
[move the changes to the SoC section]
Signed-off-by: Michael Riesch 
---
 .../devicetree/bindings/gpu/arm,mali-bifrost.yaml | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
index 63a08f3f321d..21409c8d3813 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml
@@ -159,6 +159,21 @@ allOf:
 power-domains:
   maxItems: 1
 sram-supply: false
+  - if:
+  properties:
+compatible:
+  contains:
+const: rockchip,rk3568-mali
+then:
+  properties:
+clocks:
+  minItems: 2
+clock-names:
+  items:
+   - const: core
+   - const: bus
+  required:
+- clock-names
 
 examples:
   - |
-- 
2.30.2

[PATCH v5 2/5] arm64: dts: rockchip: add gpu node to rk356x

[Michael Riesch]

From: Ezequiel Garcia 

Rockchip SoCs RK3566 and RK3568 have a Mali Gondul core
which is based on the Bifrost architecture. It has
one shader core and two execution engines.

Quoting the datasheet:

Mali-G52 1-Core-2EE
* Support 1600Mpix/s fill rate when 800MHz clock frequency
* Support 38.4GLOPs when 800MHz clock frequency

Signed-off-by: Ezequiel Garcia 
Signed-off-by: Alex Bee 
Signed-off-by: Michael Riesch 
---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi 
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index ff1689283996..47484305b7a4 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -144,6 +144,40 @@ scmi_clk: protocol@14 {
};
};
 
+   gpu_opp_table: opp-table-1 {
+   compatible = "operating-points-v2";
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   opp-microvolt = <825000>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   opp-microvolt = <825000>;
+   };
+
+   opp-4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <825000>;
+   };
+
+   opp-6 {
+   opp-hz = /bits/ 64 <6>;
+   opp-microvolt = <825000>;
+   };
+
+   opp-7 {
+   opp-hz = /bits/ 64 <7>;
+   opp-microvolt = <90>;
+   };
+
+   opp-8 {
+   opp-hz = /bits/ 64 <8>;
+   opp-microvolt = <100>;
+   };
+   };
+
pmu {
compatible = "arm,cortex-a55-pmu";
interrupts = ,
@@ -444,6 +478,21 @@ power-domain@RK3568_PD_RKVENC {
};
};
 
+   gpu: gpu@fde6 {
+   compatible = "rockchip,rk3568-mali", "arm,mali-bifrost";
+   reg = <0x0 0xfde6 0x0 0x4000>;
+   interrupts = ,
+,
+;
+   interrupt-names = "job", "mmu", "gpu";
+   clocks = <&scmi_clk 1>, <&cru CLK_GPU>;
+   clock-names = "core", "bus";
+   #cooling-cells = <2>;
+   operating-points-v2 = <&gpu_opp_table>;
+   power-domains = <&power RK3568_PD_GPU>;
+   status = "disabled";
+   };
+
sdmmc2: mmc@fe00 {
compatible = "rockchip,rk3568-dw-mshc", 
"rockchip,rk3288-dw-mshc";
reg = <0x0 0xfe00 0x0 0x4000>;
-- 
2.30.2

[PATCH v5 5/5] arm64: dts: rockchip: enable the gpu on rk3568-evb1-v10

[Michael Riesch]

Enable the GPU core on the Rockchip RK3568 EVB1.

Signed-off-by: Michael Riesch 
---
 arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts 
b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
index d8a4f7a9f562..39c495ff0157 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -140,6 +140,11 @@ &gmac1m1_rgmii_clk
status = "okay";
 };
 
+&gpu {
+   mali-supply = <&vdd_gpu>;
+   status = "okay";
+};
+
 &i2c0 {
status = "okay";
 
@@ -462,6 +467,12 @@ &sdmmc0 {
status = "okay";
 };
 
+&tsadc {
+   rockchip,hw-tshut-mode = <1>;
+   rockchip,hw-tshut-polarity = <0>;
+   status = "okay";
+};
+
 &uart2 {
status = "okay";
 };
-- 
2.30.2

[PATCH v5 4/5] arm64: dts: rockchip: enable the gpu on quartz64-a

[Michael Riesch]

From: Ezequiel Garcia 

Enable the GPU core on the Pine64 Quartz64 Model A.

Signed-off-by: Ezequiel Garcia 
Signed-off-by: Alex Bee 
Signed-off-by: Michael Riesch 
---
 arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts 
b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
index 3e65465ac7d5..b048db6cff3a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
@@ -221,6 +221,11 @@ &gmac1m0_clkinout
status = "okay";
 };
 
+&gpu {
+   mali-supply = <&vdd_gpu>;
+   status = "okay";
+};
+
 &i2c0 {
status = "okay";
 
-- 
2.30.2

Re: [PATCH v6 1/3] drm/lsdc: add drm driver for loongson display controller

[Maxime Ripard]

On Thu, Feb 03, 2022 at 11:47:16PM +0800, Sui Jingfeng wrote:
> On 2022/2/3 16:58, Maxime Ripard wrote:
> > > diff --git a/drivers/gpu/drm/lsdc/Kconfig b/drivers/gpu/drm/lsdc/Kconfig
> > > new file mode 100644
> > > index ..7ed1b0fdbe1b
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/lsdc/Kconfig
> > > @@ -0,0 +1,38 @@
> > > +config DRM_LSDC
> > > + tristate "DRM Support for loongson's display controller"
> > > + depends on DRM && PCI
> > > + depends on MACH_LOONGSON64 || LOONGARCH || MIPS || COMPILE_TEST
> > > + select OF
> > > + select CMA if HAVE_DMA_CONTIGUOUS
> > > + select DMA_CMA if HAVE_DMA_CONTIGUOUS
> > > + select DRM_KMS_HELPER
> > > + select DRM_KMS_FB_HELPER
> > > + select DRM_GEM_CMA_HELPER
> > > + select VIDEOMODE_HELPERS
> > > + select BACKLIGHT_PWM if CPU_LOONGSON2K
> > > + select I2C_GPIO if CPU_LOONGSON2K
> > > + select I2C_LS2X if CPU_LOONGSON2K
> > > + default m
> > > + help
> > > +   This is a KMS driver for the display controller in the LS7A1000
> > > +   bridge chip and LS2K1000 SoC. The display controller has two
> > > +   display pipes and it is a PCI device.
> > > +   When using this driver on LS2K1000/LS2K0500 SoC, its framebuffer
> > > +   is located at system memory.
> > > +   If "M" is selected, the module will be called lsdc.
> > > +
> > > +   If in doubt, say "Y".
> > > +
> > > +config DRM_LSDC_VRAM_DRIVER
> > > + bool "vram helper based device driver support"
> > > + depends on DRM_LSDC
> > > + select DRM_VRAM_HELPER
> > > + default y
> > > + help
> > > +   When using this driver on LS7A1000 + LS3A3000/LS3A4000/LS3A5000
> > > +   platform, the LS7A1000 bridge chip has dedicated video RAM. Using
> > > +   "lsdc.use_vram_helper=1" in the kernel command line will enable
> > > +   this driver mode and then the framebuffer will be located at the
> > > +   VRAM at the price of losing PRIME support.
> > > +
> > > +   If in doubt, say "Y".
> > This doesn't sound right. The driver should make the proper decision
> > depending on the platform, not the user or the distribution.
> 
> The LS7A1000 north bridge chip has dedicated video RAM, but the DC in LS7A1000
> can also scanout from the system memory directly like a display controller in 
> a
> SoC does. In fact, this display controller is envolved from early product of
> Loongson 2H SoC. This driver still works even if the downstream PC board
> manufacturer doesn't solder a video RAM on the mother board.
> 
> The lsdc_should_vram_helper_based() function in lsdc_drv.c will examine
> if the DC device node contain a use_vram_helper property at driver loading 
> time.
> If there is no use_vram_helper property, CMA helper based DRM driver will be 
> used.
> Doing this way allow the user using "lsdc.use_vram_helper=0" override the 
> default
> behavior even through there is a "use_vram_helper;" property in the DTS.
> 
> In short, It is intend to let the command line passed from kernel has higher
> priority than the device tree. Otherwise the end user can not switch different
> driver mode through the kernel command line once the DC device node contain
> "use_vram_helper;" property.
> 
> This driver's author already made the decision by the time when the patch is
> sent out, even through this**may not proper.
> 
> The CMA helper based driver will be used by default, if the DC device node 
> contain
> "use_vram_helper;" then VRAM based driver will be used. This is my initial 
> intention.

DT isn't really a solution either. Let's take the distribution
perspective there. Suppose you're a Fedora or Debian developer, and want
to make a single kernel image, and ship a DT to the user for their board
without any modification. How is either the Kconfig solution or DT flags
solution any good there? It doesn't help them at all.

Maxime


signature.asc
Description: PGP signature

[PATCH v3 0/4] Add support for the eDP panel on sc7280 CRD

[Sankeerth Billakanti]

Add support for the eDP panel on sc7280 CRD platform. The eDP panel does
not need HPD line for connect disconnect. So, this series will report eDP
as always connected. The driver needs to register for IRQ_HPD only for eDP.
This support will be added later.

These changes are dependent on the following series:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=586263&archive=both&state=*
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=560587&state=%2A&archive=both


Sankeerth Billakanti (4):
  dt-bindings: display: simple: Add sharp LQ140M1JW46 panel
  arm64: dts: qcom: sc7280: Add support for eDP panel on CRD
  drm/panel-edp: Add eDP sharp panel support
  drm/msm/dp: Add driver support to utilize drm panel

 .../bindings/display/panel/panel-simple.yaml   |   2 +
 arch/arm64/boot/dts/qcom/sc7280-crd.dts| 122 +
 arch/arm64/boot/dts/qcom/sc7280.dtsi   |   2 +-
 drivers/gpu/drm/msm/dp/dp_display.c|   8 ++
 drivers/gpu/drm/msm/dp/dp_drm.c|  54 -
 drivers/gpu/drm/msm/dp/dp_parser.h |   3 +
 drivers/gpu/drm/panel/panel-edp.c  |  31 ++
 7 files changed, 216 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH v3 2/4] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

[Sankeerth Billakanti]

Enable the eDP display panel support without HPD on sc7280 platform.

Signed-off-by: Sankeerth Billakanti 
---

Changes in v3:
  - Sort the nodes alphabetically
  - Use - instead of _ as node names
  - Place the backlight and panel nodes under root
  - Change the name of edp_out to mdss_edp_out
  - Change the names of regulator nodes
  - Delete unused properties in the board file


Changes in v2:
  - Sort node references alphabetically
  - Improve readability
  - Move the pwm pinctrl to pwm node
  - Move the regulators to root
  - Define backlight power
  - Remove dummy regulator node
  - Cleanup pinctrl definitions

 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 122 
 arch/arm64/boot/dts/qcom/sc7280.dtsi|   2 +-
 2 files changed, 123 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts 
b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
index e2efbdd..2a490a0 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
@@ -21,6 +21,59 @@
chosen {
stdout-path = "serial0:115200n8";
};
+
+   backlight_3v3_regulator: backlight-3v3-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "backlight_3v3_regulator";
+
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = <&pm8350c_gpios 7 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&edp_bl_power>;
+   };
+
+   edp_3v3_regulator: edp-3v3-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "edp_3v3_regulator";
+
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&edp_panel_power>;
+   };
+
+   edp_backlight: edp-backlight {
+   compatible = "pwm-backlight";
+
+   power-supply = <&backlight_3v3_regulator>;
+   pwms = <&pm8350c_pwm 3 65535>;
+   };
+
+   edp_panel: edp-panel {
+   compatible = "sharp,lq140m1jw46";
+
+   power-supply = <&edp_3v3_regulator>;
+   backlight = <&edp_backlight>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   edp_panel_in: endpoint {
+   remote-endpoint = <&edp_out>;
+   };
+   };
+   };
+   };
 };
 
 &apps_rsc {
@@ -76,6 +129,44 @@ ap_ts_pen_1v8: &i2c13 {
};
 };
 
+&mdss {
+   status = "okay";
+};
+
+&mdss_dp {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&dp_hot_plug_det>;
+   data-lanes = <0 1>;
+   vdda-1p2-supply = <&vreg_l6b_1p2>;
+   vdda-0p9-supply = <&vreg_l1b_0p8>;
+};
+
+&mdss_edp {
+   status = "okay";
+
+   vdda-1p2-supply = <&vreg_l6b_1p2>;
+   vdda-0p9-supply = <&vreg_l10c_0p8>;
+   /delete-property/ pinctrl-names;
+   /delete-property/ pinctrl-0;
+};
+
+&mdss_edp_out {
+   remote-endpoint = <&edp_panel_in>;
+};
+
+&mdss_edp_phy {
+   status = "okay";
+
+   vdda-1p2-supply = <&vreg_l6b_1p2>;
+   vdda-0p9-supply = <&vreg_l10c_0p8>;
+};
+
+&mdss_mdp {
+   status = "okay";
+};
+
 &nvme_3v3_regulator {
gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
 };
@@ -84,7 +175,38 @@ ap_ts_pen_1v8: &i2c13 {
pins = "gpio51";
 };
 
+&pm8350c_gpios {
+   edp_bl_power: edp-bl-power {
+   pins = "gpio7";
+   function = "normal";
+   qcom,drive-strength = ;
+   bias-disable;
+   output-low;
+   };
+
+   edp_bl_pwm: edp-bl-pwm {
+   pins = "gpio8";
+   function = "func1";
+   qcom,drive-strength = ;
+   bias-disable;
+   output-low;
+   };
+};
+
+&pm8350c_pwm {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&edp_bl_pwm>;
+};
+
 &tlmm {
+   edp_panel_power: edp-panel-power {
+   pins = "gpio80";
+   function = "gpio";
+   bias-pull-down;
+   };
+
tp_int_odl: tp-int-odl {
pins = "gpio7";
function = "gpio";
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 3572399..eca403a 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3066,7 +3066,7 @@
 
port@1 {
reg = <1>;
-

[PATCH v3 3/4] drm/panel-edp: Add eDP sharp panel support

[Sankeerth Billakanti]

Add support for the 14" sharp,lq140m1jw46 eDP panel.

Signed-off-by: Sankeerth Billakanti 
---

Changes in v3:
  None

 drivers/gpu/drm/panel/panel-edp.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-edp.c 
b/drivers/gpu/drm/panel/panel-edp.c
index a394a15..5d13ccc 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1605,6 +1605,34 @@ static const struct panel_desc sharp_lq123p1jx31 = {
},
 };
 
+static const struct drm_display_mode sharp_lq140m1jw46_mode = {
+   .clock = 144370,
+   .hdisplay = 1920,
+   .hsync_start = 1920 + 48,
+   .hsync_end = 1920 + 48 + 32,
+   .htotal = 1920 + 48 + 32 + 80,
+   .vdisplay = 1080,
+   .vsync_start = 1080 + 3,
+   .vsync_end = 1080 + 3 + 5,
+   .vtotal = 1080 + 3 + 5 + 69,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc sharp_lq140m1jw46 = {
+   .modes = &sharp_lq140m1jw46_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 309,
+   .height = 174,
+   },
+   .delay = {
+   .hpd_absent = 80,
+   .enable = 50,
+   .unprepare = 500,
+   },
+};
+
 static const struct drm_display_mode starry_kr122ea0sra_mode = {
.clock = 147000,
.hdisplay = 1920,
@@ -1719,6 +1747,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "sharp,lq123p1jx31",
.data = &sharp_lq123p1jx31,
}, {
+   .compatible = "sharp,lq140m1jw46",
+   .data = &sharp_lq140m1jw46,
+   }, {
.compatible = "starry,kr122ea0sra",
.data = &starry_kr122ea0sra,
}, {
-- 
2.7.4

[PATCH v3 4/4] drm/msm/dp: Add driver support to utilize drm panel

[Sankeerth Billakanti]

Add support in the DP driver to utilize the custom eDP panels
from drm/panels.

An eDP panel is always connected to the platform. So, the eDP
connector can be reported as always connected. The display mode
will be sourced from the panel. The panel mode will be set after
the link training is completed.

Signed-off-by: Sankeerth Billakanti 
---

Changes in v3:
  None

 drivers/gpu/drm/msm/dp/dp_display.c |  8 ++
 drivers/gpu/drm/msm/dp/dp_drm.c | 54 +
 drivers/gpu/drm/msm/dp/dp_parser.h  |  3 +++
 3 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index 7cc4d21..410fda4 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1513,6 +1513,10 @@ int msm_dp_display_enable(struct msm_dp *dp, struct 
drm_encoder *encoder)
return -EINVAL;
}
 
+   /* handle eDP on */
+   if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+   dp_hpd_plug_handle(dp_display, 0);
+
mutex_lock(&dp_display->event_mutex);
 
/* stop sentinel checking */
@@ -1577,6 +1581,10 @@ int msm_dp_display_disable(struct msm_dp *dp, struct 
drm_encoder *encoder)
 
dp_display = container_of(dp, struct dp_display_private, dp_display);
 
+   /* handle edp off */
+   if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+   dp_hpd_unplug_handle(dp_display, 0);
+
mutex_lock(&dp_display->event_mutex);
 
/* stop sentinel checking */
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.c b/drivers/gpu/drm/msm/dp/dp_drm.c
index d4d360d..12fa8c1 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.c
+++ b/drivers/gpu/drm/msm/dp/dp_drm.c
@@ -39,6 +39,10 @@ static enum drm_connector_status dp_connector_detect(struct 
drm_connector *conn,
 
dp = to_dp_connector(conn)->dp_display;
 
+   /* eDP is always  connected */
+   if (dp->connector_type == DRM_MODE_CONNECTOR_eDP)
+   return connector_status_connected;
+
DRM_DEBUG_DP("is_connected = %s\n",
(dp->is_connected) ? "true" : "false");
 
@@ -123,6 +127,35 @@ static enum drm_mode_status dp_connector_mode_valid(
return dp_display_validate_mode(dp_disp, mode->clock);
 }
 
+static int edp_connector_get_modes(struct drm_connector *connector)
+{
+   struct msm_dp *dp;
+
+   if (!connector)
+   return 0;
+
+   dp = to_dp_connector(connector)->dp_display;
+
+   return drm_bridge_get_modes(dp->panel_bridge, connector);
+}
+
+static enum drm_mode_status edp_connector_mode_valid(
+   struct drm_connector *connector,
+   struct drm_display_mode *mode)
+{
+   struct msm_dp *dp;
+
+   if (!connector)
+   return 0;
+
+   dp = to_dp_connector(connector)->dp_display;
+
+   if (mode->clock > EDP_MAX_PIXEL_CLK_KHZ)
+   return MODE_BAD;
+
+   return MODE_OK;
+}
+
 static const struct drm_connector_funcs dp_connector_funcs = {
.detect = dp_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -137,6 +170,12 @@ static const struct drm_connector_helper_funcs 
dp_connector_helper_funcs = {
.mode_valid = dp_connector_mode_valid,
 };
 
+static const struct drm_connector_helper_funcs edp_connector_helper_funcs = {
+   .get_modes = edp_connector_get_modes,
+   .mode_valid = edp_connector_mode_valid,
+
+};
+
 /* connector initialization */
 struct drm_connector *dp_drm_connector_init(struct msm_dp *dp_display)
 {
@@ -160,12 +199,17 @@ struct drm_connector *dp_drm_connector_init(struct msm_dp 
*dp_display)
if (ret)
return ERR_PTR(ret);
 
-   drm_connector_helper_add(connector, &dp_connector_helper_funcs);
+   if (dp_display->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   drm_connector_helper_add(connector,
+   &edp_connector_helper_funcs);
+   } else {
+   drm_connector_helper_add(connector, &dp_connector_helper_funcs);
 
-   /*
-* Enable HPD to let hpd event is handled when cable is connected.
-*/
-   connector->polled = DRM_CONNECTOR_POLL_HPD;
+   /*
+* Enable HPD to let hpd event is handled when cable is 
connected.
+*/
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
+   }
 
drm_connector_attach_encoder(connector, dp_display->encoder);
 
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h 
b/drivers/gpu/drm/msm/dp/dp_parser.h
index 3172da0..58c4f27 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -17,6 +17,9 @@
 #define DP_MAX_PIXEL_CLK_KHZ   675000
 #define DP_MAX_NUM_DP_LANES4
 
+/* Maximum validated clock */
+#define EDP_MAX_PIXEL_CLK_KHZ  285550
+
 enum dp_pm_type {
DP_CORE_PM,
DP_CTRL_PM,
-- 
2.7.4

[PATCH v3 1/4] dt-bindings: display: simple: Add sharp LQ140M1JW46 panel

[Sankeerth Billakanti]

Add support for sharp LQ140M1JW46 display panel. It is a 14" eDP panel
with 1920x1080 display resolution.

Signed-off-by: Sankeerth Billakanti 
---

Changes in v3:
  None

 Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 9cf5588..1eb9dd4 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -284,6 +284,8 @@ properties:
   - sharp,lq101k1ly04
 # Sharp 12.3" (2400x1600 pixels) TFT LCD panel
   - sharp,lq123p1jx31
+# Sharp 14" (1920x1080 pixels) TFT LCD panel
+  - sharp,lq140m1jw46
 # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel
   - sharp,ls020b1dd01d
 # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel
-- 
2.7.4

[PATCH v3 1/7] drm/format-helper: Add drm_fb_xrgb8888_to_gray8_line()

[Javier Martinez Canillas]

Pull the per-line conversion logic into a separate helper function.

This will allow to do line-by-line conversion in other helpers that
convert to a gray8 format.

Suggested-by: Thomas Zimmermann 
Signed-off-by: Javier Martinez Canillas 
---

Changes in v3:
- Add a drm_fb_xrgb_to_gray8_line() helper function (Thomas Zimmermann)

 drivers/gpu/drm/drm_format_helper.c | 31 ++---
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index 0f28dd2bdd72..b981712623d3 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -464,6 +464,21 @@ void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst,
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_toio);
 
+static void drm_fb_xrgb_to_gray8_line(u8 *dst, const u32 *src, unsigned 
int pixels)
+{
+   unsigned int x;
+
+   for (x = 0; x < pixels; x++) {
+   u8 r = (*src & 0x00ff) >> 16;
+   u8 g = (*src & 0xff00) >> 8;
+   u8 b =  *src & 0x00ff;
+
+   /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
+   *dst++ = (3 * r + 6 * g + b) / 10;
+   src++;
+   }
+}
+
 /**
  * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
@@ -484,8 +499,9 @@ EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_toio);
 void drm_fb_xrgb_to_gray8(void *dst, unsigned int dst_pitch, const void 
*vaddr,
  const struct drm_framebuffer *fb, const struct 
drm_rect *clip)
 {
-   unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
-   unsigned int x, y;
+   unsigned int linepixels = clip->x2 - clip->x1;
+   unsigned int len = linepixels * sizeof(u32);
+   unsigned int y;
void *buf;
u8 *dst8;
u32 *src32;
@@ -508,16 +524,7 @@ void drm_fb_xrgb_to_gray8(void *dst, unsigned int 
dst_pitch, const void *vad
for (y = clip->y1; y < clip->y2; y++) {
dst8 = dst;
src32 = memcpy(buf, vaddr, len);
-   for (x = clip->x1; x < clip->x2; x++) {
-   u8 r = (*src32 & 0x00ff) >> 16;
-   u8 g = (*src32 & 0xff00) >> 8;
-   u8 b =  *src32 & 0x00ff;
-
-   /* ITU BT.601: Y = 0.299 R + 0.587 G + 0.114 B */
-   *dst8++ = (3 * r + 6 * g + b) / 10;
-   src32++;
-   }
-
+   drm_fb_xrgb_to_gray8_line(dst8, src32, linepixels);
vaddr += fb->pitches[0];
dst += dst_pitch;
}
-- 
2.34.1

[PATCH v3 0/7] drm: Add driver for Solomon SSD130X OLED displays

[Javier Martinez Canillas]

This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.

Using the DRM fb emulation, all the tests from Geert Uytterhoeven's fbtest
(https://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git) passes.

I've also tested it using the display as a VT output and even though fbcon
seems to work, it is mostly unusable on a 128x64 SSD1306 display.

This is a v3 that addresses all the issues pointed in v2. Thanks a lot
to everyone that gave me feedback and reviews.

Patch #1 splits per-line conversion logic in drm_fb_xrgb_to_gray8() to
a separate drm_fb_xrgb_to_gray8_line() helper function.

Patch #2 adds two new helpers, drm_fb_gray8_to_mono_reversed() to convert
from grayscale to monochrome and a drm_fb_xrgb_to_mono_reversed() to
convert from XR24 to monochrome. The latter internally converts each line
first to gray8 and then to reversed monochrome.

Patch #3 adds the driver. This only has the core support but doesn't have
any bus specific code, separate drivers are needed for the transport used.

Patch #4 adds a driver to use the I2C bus to communicate with the device
and patch #5 adds a similar driver for SPI. This one is a WIP and wasn't
tested. I'm including for people to test and modify for their displays.

Patch #6 just adds a MAINTAINERS entry for the DRM driver and patch #7
adds myself as a co-maintainer of the existing Device Tree binding for
ssd1307fb, since the same is shared between the fbdev and DRM drivers.

Best regards,
Javier

Changes in v3:
- Add a drm_fb_xrgb_to_gray8_line() helper function (Thomas Zimmermann)
- Also add a drm_fb_xrgb_to_mono_reversed() helper (Thomas Zimmermann)
- Split lines copy to drm_fb_gray8_to_mono_reversed_line() (Thomas Zimmermann)
- Handle case where the source buffer is not aligned to 8 (Thomas Zimmermann)
- Move driver from tiny sub-dir to drivers/gpu/drm/solomon (Sam Ravnborg)
- Split driver in a bus agnostic core and bus specific (Andy Shevchenko)
- Use regmap to access the chip registers (Andy Shevchenko)
- Remove unnecessary blank lines (Andy Shevchenko)
- Remove unneeded inline specifier in functions (Andy Shevchenko)
- Add a comment about always returning a single mode (Andy Shevchenko)
- Change write command logic to use do while loop (Andy Shevchenko)
- Use "firmware description" instead of "device tree" (Andy Shevchenko)
- Use return foo() instead of returning the return value (Andy Shevchenko)
- Don't split lines longer than 80 chars if makes less readable (Andy 
Shevchenko)
- Remove redundant else statements in .mode_valid callback (Andy Shevchenko)
- Rename powero{n,ff}() functions to power_o{n,ff)() (Andy Shevchenko)
- Use dev_err_probe() to prevent spam logs on probe deferral (Andy Shevchenko)
- Remove ',' after sentinel terminator in array (Andy Shevchenko)
- Fix a bug when doing partial updates (Geert Uytterhoeven)
- Add a separate driver for SSD130X chips I2C support (Andy Shevchenko)
- Add a separate driver for SSD130X chips SPI support (Andy Shevchenko)
- Adapt MAINTAINERS entry to point to the new drivers/gpu/drm/solomon directory.

Changes in v2:
- Drop patch that was adding a DRM_MODE_CONNECTOR_I2C type.
- Invert order of backlight {en,dis}able and display {on,off} (Sam Ravnborg)
- Don't clear the screen and turn on display on probe (Sam Ravnborg)
- Use backlight_get_brightness() macro to get BL brightness (Sam Ravnborg)
- Use dev managed version of devm_backlight_device_register() (Sam Ravnborg)
- Use dev_name(dev) for backlight name instead of an array (Sam Ravnborg)
- Drop the .get_brightness callback since isn't needed  (Sam Ravnborg)
- Rename driver to ssd130x since supports a display family (Thomas Zimmermann)
- Drop the TINY prefix from the Kconfig symbol (Thomas Zimmermann)
- Sort the Kconfig symbol dependencies alphabetically (Thomas Zimmermann)
- Rename struct ssd130x_array to struct ssd130x_i2c_msg (Thomas Zimmermann)
- Rename struct ssd130x_i2c_msg .type member to .cmd (Thomas Zimmermann)
- Use sizeof(*foo) instead of sizeof(struct foo) (Thomas Zimmermann)
- Use struct_size() macro to calculate sizeof(*foo) + len (Thomas Zimmermann)
- Use kcalloc() instead of kmalloc_array() + memset() (Thomas Zimmermann)
- Use shadow plane helpers virtual screen support (Thomas Zimmermann)
- Remove unused goto label in ssd1307_fb_blit_rect() (Thomas Zimmermann)
- Use drm_set_preferred_mode() inset of manually set (Thomas Zimmermann)
- Use shadow plane helpers virtual screen support (Thomas Zimmermann)
- Remove unused goto label in ssd1307_fb_blit_rect() (Thomas Zimmermann)
- Use drm_set_preferred_mode() inset of manually set (Thomas Zimmermann)
- Reorganize code in probe to make it more legible (Thomas Zimmermann)
- ssd130x_write_cmd() uses varargs to simplify I2C code (Thomas Zimmermann)
- Move regulator/pwm init logic to display pipe enable callback.
- Add Sam Ravnborg's acked-by to patch adding a MAINTAINERS entry (Sam Ravnborg

[PATCH v3 3/7] drm: Add driver for Solomon SSD130X OLED displays

[Javier Martinez Canillas]

This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
OLED display controllers.

It's only the core part of the driver and a bus specific driver is needed
for each transport interface supported by the display controllers.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3:
- Move driver from tiny sub-dir to drivers/gpu/drm/solomon (Sam Ravnborg)
- Split driver in a bus agnostic core and bus specific (Andy Shevchenko)
- Use regmap to access the chip registers (Andy Shevchenko)
- Remove unnecessary blank lines (Andy Shevchenko)
- Remove unneeded inline specifier in functions (Andy Shevchenko)
- Add a comment about always returning a single mode (Andy Shevchenko)
- Change write command logic to use do while loop (Andy Shevchenko)
- Use "firmware description" instead of "device tree" (Andy Shevchenko)
- Use return foo() instead of returning the return value (Andy Shevchenko)
- Don't split lines longer than 80 chars if makes less readable (Andy 
Shevchenko)
- Remove redundant else statements in .mode_valid callback (Andy Shevchenko)
- Rename powero{n,ff}() functions to power_o{n,ff)() (Andy Shevchenko)
- Use dev_err_probe() to prevent spam logs on probe deferral (Andy Shevchenko)
- Remove ',' after sentinel terminator in array (Andy Shevchenko)
- Fix a bug when doing partial updates (Geert Uytterhoeven)

Changes in v2:
- Drop patch that was adding a DRM_MODE_CONNECTOR_I2C type.
- Invert order of backlight {en,dis}able and display {on,off} (Sam Ravnborg)
- Don't clear the screen and turn on display on probe (Sam Ravnborg)
- Use backlight_get_brightness() macro to get BL brightness (Sam Ravnborg)
- Use dev managed version of devm_backlight_device_register() (Sam Ravnborg)
- Use dev_name(dev) for backlight name instead of an array (Sam Ravnborg)
- Drop the .get_brightness callback since isn't needed  (Sam Ravnborg)
- Rename driver to ssd130x since supports a display family (Thomas Zimmermann)
- Drop the TINY prefix from the Kconfig symbol (Thomas Zimmermann)
- Sort the Kconfig symbol dependencies alphabetically (Thomas Zimmermann)
- Rename struct ssd130x_array to struct ssd130x_i2c_msg (Thomas Zimmermann)
- Rename struct ssd130x_i2c_msg .type member to .cmd (Thomas Zimmermann)
- Use sizeof(*foo) instead of sizeof(struct foo) (Thomas Zimmermann)
- Use struct_size() macro to calculate sizeof(*foo) + len (Thomas Zimmermann)
- Use kcalloc() instead of kmalloc_array() + memset() (Thomas Zimmermann)
- Use shadow plane helpers virtual screen support (Thomas Zimmermann)
- Remove unused goto label in ssd1307_fb_blit_rect() (Thomas Zimmermann)
- Use drm_set_preferred_mode() inset of manually set (Thomas Zimmermann)
- Use shadow plane helpers virtual screen support (Thomas Zimmermann)
- Remove unused goto label in ssd1307_fb_blit_rect() (Thomas Zimmermann)
- Use drm_set_preferred_mode() inset of manually set (Thomas Zimmermann)
- Reorganize code in probe to make it more legible (Thomas Zimmermann)
- ssd130x_write_cmd() uses varargs to simplify I2C code (Thomas Zimmermann)
- Move regulator/pwm init logic to display pipe enable callback.

 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/solomon/Kconfig   |  12 +
 drivers/gpu/drm/solomon/Makefile  |   1 +
 drivers/gpu/drm/solomon/ssd130x.c | 823 ++
 drivers/gpu/drm/solomon/ssd130x.h |  76 +++
 6 files changed, 915 insertions(+)
 create mode 100644 drivers/gpu/drm/solomon/Kconfig
 create mode 100644 drivers/gpu/drm/solomon/Makefile
 create mode 100644 drivers/gpu/drm/solomon/ssd130x.c
 create mode 100644 drivers/gpu/drm/solomon/ssd130x.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index dfdd3ec5f793..c423c920c027 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -405,6 +405,8 @@ source "drivers/gpu/drm/gud/Kconfig"
 
 source "drivers/gpu/drm/sprd/Kconfig"
 
+source "drivers/gpu/drm/solomon/Kconfig"
+
 config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
depends on DRM && PCI && MMU && HYPERV
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8675c2af7ae1..a07b777e778a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -133,3 +133,4 @@ obj-y   += xlnx/
 obj-y  += gud/
 obj-$(CONFIG_DRM_HYPERV) += hyperv/
 obj-$(CONFIG_DRM_SPRD) += sprd/
+obj-y  += solomon/
diff --git a/drivers/gpu/drm/solomon/Kconfig b/drivers/gpu/drm/solomon/Kconfig
new file mode 100644
index ..c969c358a4a7
--- /dev/null
+++ b/drivers/gpu/drm/solomon/Kconfig
@@ -0,0 +1,12 @@
+config DRM_SSD130X
+   tristate "DRM support for Solomon SSD130X OLED displays"
+   depends on DRM
+   select BACKLIGHT_CLASS_DEVICE
+   select DRM_GEM_SHMEM_HELPER
+   select DRM_KMS_HELPER
+   help
+ DRM driver for the SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
+ OLED controllers. This is only for the core 

[PATCH v3 2/7] drm/format-helper: Add drm_fb_{xrgb8888, gray8}_to_mono_reversed()

[Javier Martinez Canillas]

Add support to convert XR24 and 8-bit grayscale to reversed monochrome for
drivers that control monochromatic panels, that only have 1 bit per pixel.

The drm_fb_gray8_to_mono_reversed() helper was based on the function that
does the same in the drivers/gpu/drm/tiny/repaper.c driver.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3:
- Also add a drm_fb_xrgb_to_mono_reversed() helper (Thomas Zimmermann)
- Split lines copy to drm_fb_gray8_to_mono_reversed_line() (Thomas Zimmermann)
- Handle case where the source buffer is not aligned to 8 (Thomas Zimmermann)

 drivers/gpu/drm/drm_format_helper.c | 157 
 include/drm/drm_format_helper.h |   8 ++
 2 files changed, 165 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index b981712623d3..19710342c0de 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -591,3 +591,160 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
return -EINVAL;
 }
 EXPORT_SYMBOL(drm_fb_blit_toio);
+
+static void drm_fb_gray8_to_mono_reversed_line(u8 *dst, const u8 *src, 
unsigned int pixels,
+  unsigned int start_offset, 
unsigned int end_offset)
+{
+   unsigned int xb, i;
+
+   for (xb = 0; xb < pixels; xb++) {
+   unsigned int start = 0, end = 8;
+   u8 byte = 0x00;
+
+   if (xb == 0 && start_offset)
+   start = start_offset;
+
+   if (xb == pixels - 1 && end_offset)
+   end = end_offset;
+
+   for (i = start; i < end; i++) {
+   unsigned int x = xb * 8 + i;
+
+   byte >>= 1;
+   if (src[x] >> 7)
+   byte |= BIT(7);
+   }
+   *dst++ = byte;
+   }
+}
+
+/**
+ * drm_fb_gray8_to_mono_reversed - Convert grayscale to reversed monochrome
+ * @dst: reversed monochrome destination buffer
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @src: 8-bit grayscale source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * DRM doesn't have native monochrome or grayscale support.
+ * Such drivers can announce the commonly supported XR24 format to userspace
+ * and use drm_fb_xrgb_to_gray8() to convert to grayscale and then this
+ * helper function to convert to the native format.
+ */
+void drm_fb_gray8_to_mono_reversed(void *dst, unsigned int dst_pitch, const 
void *vaddr,
+  const struct drm_framebuffer *fb,
+  const struct drm_rect *clip)
+{
+
+   unsigned int linepixels = drm_rect_width(clip);
+   unsigned int lines = drm_rect_height(clip);
+   unsigned int start_offset, end_offset;
+   unsigned int y;
+   const u8 *gray8 = vaddr;
+   u8 *mono = dst;
+
+   /*
+* The reversed mono destination buffer contains 1 bit per pixel
+* and destination scanlines have to be in multiple of 8 pixels.
+*/
+   if (!dst_pitch)
+   dst_pitch = DIV_ROUND_UP(linepixels, 8);
+
+   /*
+* For damage handling, it is possible that only parts of the source
+* buffer is copied and this could lead to start and end pixels that
+* are not aligned to multiple of 8.
+*
+* Calculate if the start and end pixels are not aligned and set the
+* offsets for the reversed mono line conversion function to adjust.
+*/
+   start_offset = clip->x1 % 8;
+   end_offset = clip->x2 % 8;
+
+   for (y = 0; y < lines; y++) {
+   drm_fb_gray8_to_mono_reversed_line(mono, gray8, dst_pitch,
+  start_offset, end_offset);
+   gray8 += fb->pitches[0];
+   mono += dst_pitch;
+   }
+}
+
+/**
+ * drm_fb_xrgb_to_mono_reversed - Convert XRGB to reversed monochrome
+ * @dst: reversed monochrome destination buffer
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @src: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * DRM doesn't have native monochrome support.
+ * Such drivers can announce the commonly supported XR24 format to userspace
+ * and use this function to convert to the native format.
+ *
+ * This function uses drm_fb_xrgb_to_gray8() to convert to grayscale and
+ * then the result is converted from grayscale to reversed monohrome.
+ */
+void drm_fb_xrgb_to_mono_reversed(void *dst, unsigned int dst_pitch, const 
void *vaddr,
+ const struct drm_framebuffer *fb, const 
struct drm_rect *clip)
+{
+   unsigned int linepixels = drm_rect_width(clip);
+   unsigned int lines = clip->y2 - clip->y1;
+   unsigned int cpp = fb->format->cp

[PATCH v3 4/7] drm/solomon: Add SSD130X OLED displays I2C support

[Javier Martinez Canillas]

The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over I2C.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3:
- Add a separate driver for SSD130X chips I2C support (Andy Shevchenko)

 drivers/gpu/drm/solomon/Kconfig   |   9 ++
 drivers/gpu/drm/solomon/Makefile  |   1 +
 drivers/gpu/drm/solomon/ssd130x-i2c.c | 117 ++
 3 files changed, 127 insertions(+)
 create mode 100644 drivers/gpu/drm/solomon/ssd130x-i2c.c

diff --git a/drivers/gpu/drm/solomon/Kconfig b/drivers/gpu/drm/solomon/Kconfig
index c969c358a4a7..47e16bc20e0d 100644
--- a/drivers/gpu/drm/solomon/Kconfig
+++ b/drivers/gpu/drm/solomon/Kconfig
@@ -10,3 +10,12 @@ config DRM_SSD130X
  the appropriate bus transport in your chip also must be selected.
 
  If M is selected the module will be called ssd130x.
+
+config DRM_SSD130X_I2C
+   tristate "DRM support for Solomon SSD130X OLED displays (I2C bus)"
+   depends on DRM_SSD130X && I2C
+   select REGMAP_I2C
+   help
+ Say Y here if the SSD130X OLED display is connected via I2C bus.
+
+ If M is selected the module will be called ssd130x-i2c.
diff --git a/drivers/gpu/drm/solomon/Makefile b/drivers/gpu/drm/solomon/Makefile
index f685addb19fe..4bfc5acb0447 100644
--- a/drivers/gpu/drm/solomon/Makefile
+++ b/drivers/gpu/drm/solomon/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_SSD130X)  += ssd130x.o
+obj-$(CONFIG_DRM_SSD130X_I2C)  += ssd130x-i2c.o
diff --git a/drivers/gpu/drm/solomon/ssd130x-i2c.c 
b/drivers/gpu/drm/solomon/ssd130x-i2c.c
new file mode 100644
index ..ff5f8992b2ff
--- /dev/null
+++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * DRM driver for Solomon SSD130X OLED displays (I2C bus)
+ *
+ * Copyright 2022 Red Hat Inc.
+ * Authors: Javier Martinez Canillas 
+ *
+ * Based on drivers/video/fbdev/ssd1307fb.c
+ * Copyright 2012 Free Electrons
+ */
+#include 
+#include 
+
+#include "ssd130x.h"
+
+#define DRIVER_NAME"ssd130x-i2c"
+#define DRIVER_DESC"DRM driver for Solomon SSD130X OLED displays (I2C)"
+
+static const struct regmap_config ssd130x_i2c_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+};
+
+static int ssd130x_i2c_probe(struct i2c_client *client)
+{
+   struct ssd130x_device *ssd130x;
+   struct regmap *regmap;
+
+   regmap = devm_regmap_init_i2c(client, &ssd130x_i2c_regmap_config);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   ssd130x = ssd130x_probe(&client->dev, regmap);
+
+   if (IS_ERR(ssd130x))
+   return PTR_ERR(ssd130x);
+
+   i2c_set_clientdata(client, ssd130x);
+
+   return 0;
+}
+
+static int ssd130x_i2c_remove(struct i2c_client *client)
+{
+   struct ssd130x_device *ssd130x = i2c_get_clientdata(client);
+
+   return ssd130x_remove(ssd130x);
+}
+
+static void ssd130x_i2c_shutdown(struct i2c_client *client)
+{
+   struct ssd130x_device *ssd130x = i2c_get_clientdata(client);
+
+   ssd130x_shutdown(ssd130x);
+}
+
+static struct ssd130x_deviceinfo ssd130x_ssd1305_deviceinfo = {
+   .default_vcomh = 0x34,
+   .default_dclk_div = 1,
+   .default_dclk_frq = 7,
+};
+
+static struct ssd130x_deviceinfo ssd130x_ssd1306_deviceinfo = {
+   .default_vcomh = 0x20,
+   .default_dclk_div = 1,
+   .default_dclk_frq = 8,
+   .need_chargepump = 1,
+};
+
+static struct ssd130x_deviceinfo ssd130x_ssd1307_deviceinfo = {
+   .default_vcomh = 0x20,
+   .default_dclk_div = 2,
+   .default_dclk_frq = 12,
+   .need_pwm = 1,
+};
+
+static struct ssd130x_deviceinfo ssd130x_ssd1309_deviceinfo = {
+   .default_vcomh = 0x34,
+   .default_dclk_div = 1,
+   .default_dclk_frq = 10,
+};
+
+static const struct of_device_id ssd130x_of_match[] = {
+   {
+   .compatible = "solomon,ssd1305fb-i2c",
+   .data = (void *)&ssd130x_ssd1305_deviceinfo,
+   },
+   {
+   .compatible = "solomon,ssd1306fb-i2c",
+   .data = (void *)&ssd130x_ssd1306_deviceinfo,
+   },
+   {
+   .compatible = "solomon,ssd1307fb-i2c",
+   .data = (void *)&ssd130x_ssd1307_deviceinfo,
+   },
+   {
+   .compatible = "solomon,ssd1309fb-i2c",
+   .data = (void *)&ssd130x_ssd1309_deviceinfo,
+   },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ssd130x_of_match);
+
+static struct i2c_driver ssd130x_i2c_driver = {
+   .driver = {
+   .name = DRIVER_NAME,
+   .of_match_table = ssd130x_of_match,
+   },
+   .probe_new = ssd130x_i2c_probe,
+   .remove = ssd130x_i2c_remove,
+   .shutdown = ssd130x_i2c_shutdown,
+};
+module_i2c_driver(ssd130x_i2c_driver);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_AUTHOR("Javier Martinez Canillas ");
+MODULE_LICENSE("GPL v2");
-- 
2.34.1

Re: [PATCH v2 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

[Maxime Ripard]

Hi Noralf,

On Tue, Feb 08, 2022 at 01:16:44PM +0100, Noralf Trønnes wrote:
> Den 08.02.2022 00.20, skrev Rob Herring:
> > On Thu, Jan 27, 2022 at 10:37:22AM +0100, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Tue, Jan 25, 2022 at 06:56:58PM +0100, Noralf Trønnes wrote:
> >>> Add binding for MIPI DBI compatible SPI panels.
> >>>
> >>> v2:
> >>> - Fix path for panel-common.yaml
> >>> - Use unevaluatedProperties
> >>> - Drop properties which are in the allOf section
> >>> - Drop model property (Rob)
> >>>
> >>> Signed-off-by: Noralf Trønnes 
> >>> ---
> >>>  .../display/panel/panel-mipi-dbi-spi.yaml | 59 +++
> >>>  1 file changed, 59 insertions(+)
> >>>  create mode 100644 
> >>> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> >>>
> >>> diff --git 
> >>> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml 
> >>> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> >>> new file mode 100644
> >>> index ..b7cbeea0f8aa
> >>> --- /dev/null
> >>> +++ 
> >>> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> >>> @@ -0,0 +1,59 @@
> >>> +# SPDX-License-Identifier: GPL-2.0-only
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: MIPI DBI SPI Panels Device Tree Bindings
> >>> +
> >>> +maintainers:
> >>> +  - Noralf Trønnes 
> >>> +
> >>> +description:
> >>> +  This binding is for display panels using a MIPI DBI controller
> >>> +  in SPI mode.
> >>> +
> >>> +allOf:
> >>> +  - $ref: panel-common.yaml#
> >>> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
> >>> +
> >>> +properties:
> >>> +  compatible:
> >>> +const: panel-mipi-dbi-spi
> >>
> >> You need contains here, otherwise it will error out if you have two 
> >> compatibles.
> > 
> > Shouldn't it always have 2?
> > 
> > Either way, this has to be split up between a common, shareable schema 
> > and specific, complete schema(s). Like this:
> > 
> > - A schema for everything common (that allows additional properties)
> > 
> > - A schema for 'panel-mipi-dbi-spi' referencing the common schema plus 
> >   'unevaluatedProperties: false'
> > 
> > - Schemas for panels with their own additional properties (regulators, 
> >   GPIOs, etc.)
> > 
> > LVDS was restructured like this IIRC.
>
> The whole point of this exercise is to avoid the need for controller
> specific bindings.

I'm not sure to follow you here, nothing that either Rob or I discussed
would require a controller specific binding.

It would require a controller compatible, but the binding itself can
just mandate a controller compatible in addition to the
panel-mipi-dbi-spi compatible, without enforcing anything wrt the
compatible itself.

And the driver will just match panel-mipi-dbi-spi so there won't be any
driver change either?

In essence, it would be similar to the bindings of panel-lvds or the
AT24 EEPROM binding: you have two compatibles, but the driver is generic
and will just infer its behaviour based on the DT properties (and in our
case will load a firmware based on the specific compatible).

Wouldn't that work?

> This binding will cover all specifics about these
> controllers except for one thing and that is the controller
> configuration. Each controller has its own configuration commands. These
> commands will be loaded as a firmware file based on the compatible and
> applied by the driver.
> 
> So this binding, the panel-common and spi-peripheral-props covers
> everything except for the controller configuration.
> 
> Here's a copy of the DBI spec: https://www.docin.com/p-219732497.html
> 
> This is my current version of the binding:
> 
> # SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> %YAML 1.2
> ---
> $id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
> 
> title: MIPI DBI SPI Panel
> 
> maintainers:
>   - Noralf Trønnes 
> 
> description: |
>   This binding is for display panels using a MIPI DBI compatible controller
>   in SPI mode.
> 
>   The MIPI Alliance Standard for Display Bus Interface defines the
> electrical
>   and logical interfaces for display controllers historically used in mobile
>   phones. The standard defines 4 display architecture types and this
> binding is
>   for type 1 which has full frame memory. There are 3 interface types in the
>   standard and type C is the serial interface.
> 
>   The standard defines the following interface signals for type C:
>   - Power:
> - Vdd: Power supply for display module
> - Vddi: Logic level supply for interface signals
> Combined into one in this binding called: power-supply
>   - Interface:
> - CSx: Chip select
> - SCL: Serial clock
> - Dout: Serial out
> - Din: Serial in
> - SDA: Bidrectional in/out
> - D/CX: Data/command selection, high=data, 

Re: [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API

[Jani Nikula]

On Wed, 09 Feb 2022, Christoph Hellwig  wrote:
> On Tue, Feb 08, 2022 at 05:15:00PM +0200, Jani Nikula wrote:
>> >  #ifdef CONFIG_DRM_I915_GVT
>> > +
>> > +#define D_BDW   (1 << 0)
>> > +#define D_SKL (1 << 1)
>> > +#define D_KBL (1 << 2)
>> > +#define D_BXT (1 << 3)
>> > +#define D_CFL (1 << 4)
>> > +
>> > +#define D_GEN9PLUS(D_SKL | D_KBL | D_BXT | D_CFL)
>> > +#define D_GEN8PLUS(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>> > +
>> > +#define D_SKL_PLUS(D_SKL | D_KBL | D_BXT | D_CFL)
>> > +#define D_BDW_PLUS(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>> > +
>> > +#define D_PRE_SKL (D_BDW)
>> > +#define D_ALL (D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>> 
>> If these really need to be in a header in i915/, I think they need to be
>> longer with some namespacing or something. I do wish these could be
>> hidden though.
>
> I think we could actually kill them off entirely.  They are used as
> arguments to the macros that setup the mmio table.
>
> Thefunctions to build these tabls are already organized by families,
> so we'd need relatively few conditions to just build them the right
> way.  There also are some runtime checks in the callbacks, but they
> seem entirely superflous as far as I can tell.
>
> Only the cmd parser is a bit messy.  So maybe we could keep these
> constants just for the cmd parser inside of gvt for now (and clean
> that up later) and remove them entirely from the mmio table.

I'm fine with cleaning this up in follow-up, provided the follow-up
actually happens! ;)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v2 6/8] drm/i915/dp: add 128b/132b support to link status checks

[Jani Nikula]

On Tue, 08 Feb 2022, Ville Syrjälä  wrote:
> On Thu, Feb 03, 2022 at 11:03:55AM +0200, Jani Nikula wrote:
>> Abstract link status check to a function that takes 128b/132b and 8b/10b
>> into account, and use it. Also dump link status on failures.
>> 
>> Cc: Uma Shankar 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/display/intel_dp.c   | 39 ++-
>>  .../drm/i915/display/intel_dp_link_training.c |  2 +-
>>  .../drm/i915/display/intel_dp_link_training.h |  4 ++
>>  3 files changed, 34 insertions(+), 11 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 146b83916005..8c5590f0409a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -3628,6 +3628,32 @@ static void intel_dp_handle_test_request(struct 
>> intel_dp *intel_dp)
>>  "Could not write test response to sink\n");
>>  }
>>  
>> +static bool intel_dp_link_ok(struct intel_dp *intel_dp,
>> + u8 link_status[DP_LINK_STATUS_SIZE])
>> +{
>> +struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
>> +struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>> +bool uhbr = intel_dp->link_rate >= 100;
>> +bool ok;
>> +
>> +if (uhbr)
>> +ok = drm_dp_128b132b_lane_channel_eq_done(link_status,
>> +  intel_dp->lane_count);
>
> I was pondering whether we need to check more of the bits here. I guess
> time will tell.
>
> Remainder of the series is
> Reviewed-by: Ville Syrjälä 

Just to be on the safe side, does this cover patches 2 and 4 too?

And thanks for all the reviews so far, much appreciated!

BR,
Jani.


>
>> +else
>> +ok = drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
>> +
>> +if (ok)
>> +return true;
>> +
>> +intel_dp_dump_link_status(intel_dp, DP_PHY_DPRX, link_status);
>> +drm_dbg_kms(&i915->drm,
>> +"[ENCODER:%d:%s] %s link not ok, retraining\n",
>> +encoder->base.base.id, encoder->base.name,
>> +uhbr ? "128b/132b" : "8b/10b");
>> +
>> +return false;
>> +}
>> +
>>  static void
>>  intel_dp_mst_hpd_irq(struct intel_dp *intel_dp, u8 *esi, u8 *ack)
>>  {
>> @@ -3658,14 +3684,7 @@ static bool intel_dp_mst_link_status(struct intel_dp 
>> *intel_dp)
>>  return false;
>>  }
>>  
>> -if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
>> -drm_dbg_kms(&i915->drm,
>> -"[ENCODER:%d:%s] channel EQ not ok, retraining\n",
>> -encoder->base.base.id, encoder->base.name);
>> -return false;
>> -}
>> -
>> -return true;
>> +return intel_dp_link_ok(intel_dp, link_status);
>>  }
>>  
>>  /**
>> @@ -3779,8 +3798,8 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
>>  intel_dp->lane_count))
>>  return false;
>>  
>> -/* Retrain if Channel EQ or CR not ok */
>> -return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
>> +/* Retrain if link not ok */
>> +return !intel_dp_link_ok(intel_dp, link_status);
>>  }
>>  
>>  static bool intel_dp_has_connector(struct intel_dp *intel_dp,
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
>> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> index cc2b82d9114c..0686da36c428 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>> @@ -712,7 +712,7 @@ static bool intel_dp_adjust_request_changed(const struct 
>> intel_crtc_state *crtc_
>>  return false;
>>  }
>>  
>> -static void
>> +void
>>  intel_dp_dump_link_status(struct intel_dp *intel_dp, enum drm_dp_phy dp_phy,
>>const u8 link_status[DP_LINK_STATUS_SIZE])
>>  {
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h 
>> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
>> index dbfb15705aaa..dc1556b46b85 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
>> @@ -29,6 +29,10 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
>>  void intel_dp_stop_link_train(struct intel_dp *intel_dp,
>>const struct intel_crtc_state *crtc_state);
>>  
>> +void
>> +intel_dp_dump_link_status(struct intel_dp *intel_dp, enum drm_dp_phy dp_phy,
>> +  const u8 link_status[DP_LINK_STATUS_SIZE]);
>> +
>>  /* Get the TPSx symbol type of the value programmed to 
>> DP_TRAINING_PATTERN_SET */
>>  static inline u8 intel_dp_training_pattern_symbol(u8 pattern)
>>  {
>> -- 
>> 2.30.2

-- 
Jani Nikula, Intel Open Source Graphics Center

[PATCH v3 5/7] (WIP) drm/solomon: Add SSD130X OLED displays SPI support

[Javier Martinez Canillas]

The ssd130x driver only provides the core support for these devices but it
does not have any bus transport logic. Add a driver to interface over SPI.

Signed-off-by: Javier Martinez Canillas 
---

Changes in v3:
- Add a separate driver for SSD130X chips SPI support (Andy Shevchenko)

 drivers/gpu/drm/solomon/Kconfig   |   9 ++
 drivers/gpu/drm/solomon/Makefile  |   1 +
 drivers/gpu/drm/solomon/ssd130x-spi.c | 114 ++
 3 files changed, 124 insertions(+)
 create mode 100644 drivers/gpu/drm/solomon/ssd130x-spi.c

diff --git a/drivers/gpu/drm/solomon/Kconfig b/drivers/gpu/drm/solomon/Kconfig
index 47e16bc20e0d..16a2098f438c 100644
--- a/drivers/gpu/drm/solomon/Kconfig
+++ b/drivers/gpu/drm/solomon/Kconfig
@@ -19,3 +19,12 @@ config DRM_SSD130X_I2C
  Say Y here if the SSD130X OLED display is connected via I2C bus.
 
  If M is selected the module will be called ssd130x-i2c.
+
+config DRM_SSD130X_SPI
+   tristate "DRM support for Solomon SSD130X OLED displays (SPI bus)"
+   depends on DRM_SSD130X && SPI
+   select REGMAP_SPI
+   help
+ Say Y here if the SSD130X OLED display is connected via SPI bus.
+
+ If M is selected the module will be called ssd130x-spi.
diff --git a/drivers/gpu/drm/solomon/Makefile b/drivers/gpu/drm/solomon/Makefile
index 4bfc5acb0447..b5fc792257d7 100644
--- a/drivers/gpu/drm/solomon/Makefile
+++ b/drivers/gpu/drm/solomon/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DRM_SSD130X)  += ssd130x.o
 obj-$(CONFIG_DRM_SSD130X_I2C)  += ssd130x-i2c.o
+obj-$(CONFIG_DRM_SSD130X_SPI)  += ssd130x-spi.o
diff --git a/drivers/gpu/drm/solomon/ssd130x-spi.c 
b/drivers/gpu/drm/solomon/ssd130x-spi.c
new file mode 100644
index ..ccc56d2f3026
--- /dev/null
+++ b/drivers/gpu/drm/solomon/ssd130x-spi.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * DRM driver for Solomon SSD130X OLED displays (SPI bus)
+ *
+ * Copyright 2022 Red Hat Inc.
+ * Authors: Javier Martinez Canillas 
+ */
+#include 
+#include 
+
+#include "ssd130x.h"
+
+#define DRIVER_NAME"ssd130x-spi"
+#define DRIVER_DESC"DRM driver for Solomon SSD130X OLED displays (SPI)"
+
+static const struct regmap_config ssd130x_spi_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+};
+
+static int ssd130x_spi_probe(struct spi_device *spi)
+{
+   struct ssd130x_device *ssd130x;
+   struct regmap *regmap;
+
+   regmap = devm_regmap_init_spi(spi, &ssd130x_spi_regmap_config);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   ssd130x = ssd130x_probe(&spi->dev, regmap);
+
+   if (IS_ERR(ssd130x))
+   return PTR_ERR(ssd130x);
+
+   spi_set_drvdata(spi, ssd130x);
+
+   return 0;
+}
+
+static int ssd130x_spi_remove(struct spi_device *spi)
+{
+   struct ssd130x_device *ssd130x = spi_get_drvdata(spi);
+
+   return ssd130x_remove(ssd130x);
+}
+
+static void ssd130x_spi_shutdown(struct spi_device *spi)
+{
+   struct ssd130x_device *ssd130x = spi_get_drvdata(spi);
+
+   ssd130x_shutdown(ssd130x);
+}
+
+static struct ssd130x_deviceinfo ssd130x_ssd1305_deviceinfo = {
+   .default_vcomh = 0x34,
+   .default_dclk_div = 1,
+   .default_dclk_frq = 7,
+};
+
+static struct ssd130x_deviceinfo ssd130x_ssd1306_deviceinfo = {
+   .default_vcomh = 0x20,
+   .default_dclk_div = 1,
+   .default_dclk_frq = 8,
+   .need_chargepump = 1,
+};
+
+static struct ssd130x_deviceinfo ssd130x_ssd1307_deviceinfo = {
+   .default_vcomh = 0x20,
+   .default_dclk_div = 2,
+   .default_dclk_frq = 12,
+   .need_pwm = 1,
+};
+
+static struct ssd130x_deviceinfo ssd130x_ssd1309_deviceinfo = {
+   .default_vcomh = 0x34,
+   .default_dclk_div = 1,
+   .default_dclk_frq = 10,
+};
+
+static const struct of_device_id ssd130x_of_match[] = {
+   {
+   .compatible = "solomon,ssd1305fb-spi",
+   .data = (void *)&ssd130x_ssd1305_deviceinfo,
+   },
+   {
+   .compatible = "solomon,ssd1306fb-spi",
+   .data = (void *)&ssd130x_ssd1306_deviceinfo,
+   },
+   {
+   .compatible = "solomon,ssd1307fb-spi",
+   .data = (void *)&ssd130x_ssd1307_deviceinfo,
+   },
+   {
+   .compatible = "solomon,ssd1309fb-spi",
+   .data = (void *)&ssd130x_ssd1309_deviceinfo,
+   },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, ssd130x_of_match);
+
+static struct spi_driver ssd130x_spi_driver = {
+   .driver = {
+   .name = DRIVER_NAME,
+   .of_match_table = ssd130x_of_match,
+   },
+   .probe = ssd130x_spi_probe,
+   .remove = ssd130x_spi_remove,
+   .shutdown = ssd130x_spi_shutdown,
+};
+module_spi_driver(ssd130x_spi_driver);
+
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_AUTHOR("Javier Martinez Canillas ");
+MODULE_LICENSE("GPL v2");
-- 
2.34.1

[PATCH v3 6/7] MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver

[Javier Martinez Canillas]

To make sure that tools like the get_maintainer.pl script will suggest
to Cc me if patches are posted for this driver.

Also include the Device Tree binding for the old ssd1307fb fbdev driver
since the new DRM driver was made compatible with the existing binding.

Signed-off-by: Javier Martinez Canillas 
Acked-by: Sam Ravnborg 
---

Changes in v3:
- Adapt MAINTAINERS entry to point to the new drivers/gpu/drm/solomon directory.

Changes in v2:
- Add Sam Ravnborg's acked-by to patch adding a MAINTAINERS entry (Sam Ravnborg)

 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e3dad0d898f5..8e6e892f99f0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6163,6 +6163,13 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/repaper.txt
 F: drivers/gpu/drm/tiny/repaper.c
 
+DRM DRIVER FOR SOLOMON SSD130X OLED DISPLAYS
+M: Javier Martinez Canillas 
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+F: drivers/gpu/drm/solomon/ssd130x*
+
 DRM DRIVER FOR QEMU'S CIRRUS DEVICE
 M: Dave Airlie 
 M: Gerd Hoffmann 
-- 
2.34.1

[PATCH v3 7/7] dt-bindings: display: ssd1307fb: Add myself as binding co-maintainer

[Javier Martinez Canillas]

The ssd130x DRM driver also makes use of this Device Tree binding to allow
existing users of the fbdev driver to migrate without the need to change
their Device Trees.

Add myself as another maintainer of the binding, to make sure that I will
be on Cc when patches are proposed for it.

Suggested-by: Sam Ravnborg 
Signed-off-by: Javier Martinez Canillas 
---

(no changes since v2)

Changes in v2:
- Add myself as co-maintainer of the ssd1370fb DT binding (Sam Ravnborg).

 Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml 
b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
index 2ed2a7d0ca2f..9baafd0c42dd 100644
--- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
+++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml
@@ -8,6 +8,7 @@ title: Solomon SSD1307 OLED Controller Framebuffer
 
 maintainers:
   - Maxime Ripard 
+  - Javier Martinez Canillas 
 
 properties:
   compatible:
-- 
2.34.1

Re: [PATCH v2 6/8] drm/i915/dp: add 128b/132b support to link status checks

[Ville Syrjälä]

On Wed, Feb 09, 2022 at 11:09:41AM +0200, Jani Nikula wrote:
> On Tue, 08 Feb 2022, Ville Syrjälä  wrote:
> > On Thu, Feb 03, 2022 at 11:03:55AM +0200, Jani Nikula wrote:
> >> Abstract link status check to a function that takes 128b/132b and 8b/10b
> >> into account, and use it. Also dump link status on failures.
> >> 
> >> Cc: Uma Shankar 
> >> Cc: Ville Syrjälä 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_dp.c   | 39 ++-
> >>  .../drm/i915/display/intel_dp_link_training.c |  2 +-
> >>  .../drm/i915/display/intel_dp_link_training.h |  4 ++
> >>  3 files changed, 34 insertions(+), 11 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> >> b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index 146b83916005..8c5590f0409a 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -3628,6 +3628,32 @@ static void intel_dp_handle_test_request(struct 
> >> intel_dp *intel_dp)
> >>"Could not write test response to sink\n");
> >>  }
> >>  
> >> +static bool intel_dp_link_ok(struct intel_dp *intel_dp,
> >> +   u8 link_status[DP_LINK_STATUS_SIZE])
> >> +{
> >> +  struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> >> +  struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> >> +  bool uhbr = intel_dp->link_rate >= 100;
> >> +  bool ok;
> >> +
> >> +  if (uhbr)
> >> +  ok = drm_dp_128b132b_lane_channel_eq_done(link_status,
> >> +intel_dp->lane_count);
> >
> > I was pondering whether we need to check more of the bits here. I guess
> > time will tell.
> >
> > Remainder of the series is
> > Reviewed-by: Ville Syrjälä 
> 
> Just to be on the safe side, does this cover patches 2 and 4 too?

Yeah, pretty sure I read through all of them.

> 
> And thanks for all the reviews so far, much appreciated!
>
> BR,
> Jani.
> 
> 
> >
> >> +  else
> >> +  ok = drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> >> +
> >> +  if (ok)
> >> +  return true;
> >> +
> >> +  intel_dp_dump_link_status(intel_dp, DP_PHY_DPRX, link_status);
> >> +  drm_dbg_kms(&i915->drm,
> >> +  "[ENCODER:%d:%s] %s link not ok, retraining\n",
> >> +  encoder->base.base.id, encoder->base.name,
> >> +  uhbr ? "128b/132b" : "8b/10b");
> >> +
> >> +  return false;
> >> +}
> >> +
> >>  static void
> >>  intel_dp_mst_hpd_irq(struct intel_dp *intel_dp, u8 *esi, u8 *ack)
> >>  {
> >> @@ -3658,14 +3684,7 @@ static bool intel_dp_mst_link_status(struct 
> >> intel_dp *intel_dp)
> >>return false;
> >>}
> >>  
> >> -  if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
> >> -  drm_dbg_kms(&i915->drm,
> >> -  "[ENCODER:%d:%s] channel EQ not ok, retraining\n",
> >> -  encoder->base.base.id, encoder->base.name);
> >> -  return false;
> >> -  }
> >> -
> >> -  return true;
> >> +  return intel_dp_link_ok(intel_dp, link_status);
> >>  }
> >>  
> >>  /**
> >> @@ -3779,8 +3798,8 @@ intel_dp_needs_link_retrain(struct intel_dp 
> >> *intel_dp)
> >>intel_dp->lane_count))
> >>return false;
> >>  
> >> -  /* Retrain if Channel EQ or CR not ok */
> >> -  return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> >> +  /* Retrain if link not ok */
> >> +  return !intel_dp_link_ok(intel_dp, link_status);
> >>  }
> >>  
> >>  static bool intel_dp_has_connector(struct intel_dp *intel_dp,
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
> >> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> index cc2b82d9114c..0686da36c428 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> >> @@ -712,7 +712,7 @@ static bool intel_dp_adjust_request_changed(const 
> >> struct intel_crtc_state *crtc_
> >>return false;
> >>  }
> >>  
> >> -static void
> >> +void
> >>  intel_dp_dump_link_status(struct intel_dp *intel_dp, enum drm_dp_phy 
> >> dp_phy,
> >>  const u8 link_status[DP_LINK_STATUS_SIZE])
> >>  {
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h 
> >> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> >> index dbfb15705aaa..dc1556b46b85 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> >> @@ -29,6 +29,10 @@ void intel_dp_start_link_train(struct intel_dp 
> >> *intel_dp,
> >>  void intel_dp_stop_link_train(struct intel_dp *intel_dp,
> >>  const struct intel_crtc_state *crtc_state);
> >>  
> >> +void
> >> +intel_dp_dump_link_status(struct intel_dp *intel_dp, enum drm_dp_phy 
> >> dp_phy,
> >> +const u8 link_status[DP_LINK_STATUS_SIZE]);
> >> 

[PATCH 1/2] drm/atomic: Don't pollute crtc_state->mode_blob with error pointers

[Ville Syrjala]

From: Ville Syrjälä 

Make sure we don't assign an error pointer to crtc_state->mode_blob
as that will break all kinds of places that assume either NULL or a
valid pointer (eg. drm_property_blob_put()).

Reported-by: fuyufan 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9781722519c3..54d62fdb4ef9 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -76,15 +76,17 @@ int drm_atomic_set_mode_for_crtc(struct drm_crtc_state 
*state,
state->mode_blob = NULL;
 
if (mode) {
+   struct drm_property_blob *blob;
+
drm_mode_convert_to_umode(&umode, mode);
-   state->mode_blob =
-   drm_property_create_blob(state->crtc->dev,
-sizeof(umode),
-&umode);
-   if (IS_ERR(state->mode_blob))
-   return PTR_ERR(state->mode_blob);
+   blob = drm_property_create_blob(crtc->dev,
+   sizeof(umode), &umode);
+   if (IS_ERR(blob))
+   return PTR_ERR(blob);
 
drm_mode_copy(&state->mode, mode);
+
+   state->mode_blob = blob;
state->enable = true;
drm_dbg_atomic(crtc->dev,
   "Set [MODE:%s] for [CRTC:%d:%s] state %p\n",
-- 
2.34.1

[PATCH 2/2] drm/modes: Fix drm_mode_copy() docs

[Ville Syrjala]

From: Ville Syrjälä 

There is no object id in drm_display_mode anymore.
Remove stale comments to the contrary.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_modes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 1c72208d8133..1f4d9cd188cc 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -880,7 +880,7 @@ EXPORT_SYMBOL(drm_mode_set_crtcinfo);
  * @dst: mode to overwrite
  * @src: mode to copy
  *
- * Copy an existing mode into another mode, preserving the object id and
+ * Copy an existing mode into another mode, preserving
  * list head of the destination mode.
  */
 void drm_mode_copy(struct drm_display_mode *dst, const struct drm_display_mode 
*src)
-- 
2.34.1

Re: [PATCH v2 0/8] drm/dp, drm/i915: 128b/132b updates

[Jani Nikula]

On Thu, 03 Feb 2022, Jani Nikula  wrote:
> v2 of https://patchwork.freedesktop.org/series/99324/
>
> BR,
> Jani.
>
> Jani Nikula (8):
>   drm/dp: add drm_dp_128b132b_read_aux_rd_interval()
>   drm/dp: add 128b/132b link status helpers from DP 2.0 E11
>   drm/dp: add some new DPCD macros from DP 2.0 E11

Maarten, Maxime, Thomas, can I get an ack for merging these via
drm-intel please?

BR,
Jani.


>   drm/i915/dp: move intel_dp_prepare_link_train() call
>   drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
>   drm/i915/dp: add 128b/132b support to link status checks
>   drm/i915/mst: update slot information for 128b/132b
>   HACK: drm/i915/dp: give more time for CDS
>
>  drivers/gpu/drm/dp/drm_dp.c   |  83 +
>  drivers/gpu/drm/i915/display/intel_dp.c   |  39 ++-
>  .../drm/i915/display/intel_dp_link_training.c | 288 +-
>  .../drm/i915/display/intel_dp_link_training.h |   4 +
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  29 +-
>  include/drm/dp/drm_dp_helper.h|  24 +-
>  6 files changed, 446 insertions(+), 21 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] lima: avoid error task dump attempt when not enabled

[Javier Martinez Canillas]

Hello Erico,

On 2/5/22 19:59, Erico Nunes wrote:
> Currently when users try to run an application with lima and that hits
> an issue such as a timeout, a message saying "fail to save task state"
> and "error task list is full" is shown in dmesg.
> 
> The error task dump is a debug feature disabled by default, so the
> error task list is usually not going to be available at all.
> The message can be misleading and creates confusion in bug reports.
> 
> We can avoid that code path and that particular message when the user
> has not explicitly set the max_error_tasks parameter to enable the
> feature.
> 
> Signed-off-by: Erico Nunes 
> ---

Looks good to me. 

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

[PATCH v2] drm/lima: avoid error task dump attempt when not enabled

[Erico Nunes]

Currently when users try to run an application with lima and that hits
an issue such as a timeout, a message saying "fail to save task state"
and "error task list is full" is shown in dmesg.

The error task dump is a debug feature disabled by default, so the
error task list is usually not going to be available at all.
The message can be misleading and creates confusion in bug reports.

We can avoid that code path and that particular message when the user
has not explicitly set the max_error_tasks parameter to enable the
feature.

Signed-off-by: Erico Nunes 
Reviewed-by: Qiang Yu 
Reviewed-by: Javier Martinez Canillas 
---
v2:
- collect review tags
- update summary line to "drm/lima:"
---
 drivers/gpu/drm/lima/lima_sched.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/lima/lima_sched.c 
b/drivers/gpu/drm/lima/lima_sched.c
index 5612d73f238f..12437e42cc76 100644
--- a/drivers/gpu/drm/lima/lima_sched.c
+++ b/drivers/gpu/drm/lima/lima_sched.c
@@ -409,7 +409,8 @@ static enum drm_gpu_sched_stat 
lima_sched_timedout_job(struct drm_sched_job *job
 
drm_sched_increase_karma(&task->base);
 
-   lima_sched_build_error_task_list(task);
+   if (lima_max_error_tasks)
+   lima_sched_build_error_task_list(task);
 
pipe->task_error(pipe);
 
-- 
2.34.1

Re: [PATCH 6/9] drm/amdgpu: remove VRAM accounting

[Matthew Auld]

On Wed, 9 Feb 2022 at 08:41, Christian König
 wrote:
>
> This is provided by TTM now.
>
> Also switch man->size to bytes instead of pages and fix the double
> printing of size and usage in debugfs.
>
> Signed-off-by: Christian König 
> Tested-by: Bas Nieuwenhuizen 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c  |  6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h  |  2 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |  6 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 58 +++-
>  6 files changed, 31 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index e8440d306496..025748e9c772 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -314,7 +314,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct 
> amdgpu_device *adev,
> }
>
> total_vram = adev->gmc.real_vram_size - 
> atomic64_read(&adev->vram_pin_size);
> -   used_vram = amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
> +   used_vram = ttm_resource_manager_usage(&adev->mman.vram_mgr.manager);
> free_vram = used_vram >= total_vram ? 0 : total_vram - used_vram;
>
> spin_lock(&adev->mm_stats.lock);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 9ff4aced5da7..0beab961b18b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -678,7 +678,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
> ui64 = atomic64_read(&adev->num_vram_cpu_page_faults);
> return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
> case AMDGPU_INFO_VRAM_USAGE:
> -   ui64 = amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
> +   ui64 = 
> ttm_resource_manager_usage(&adev->mman.vram_mgr.manager);
> return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
> case AMDGPU_INFO_VIS_VRAM_USAGE:
> ui64 = amdgpu_vram_mgr_vis_usage(&adev->mman.vram_mgr);
> @@ -717,6 +717,8 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
> struct drm_amdgpu_memory_info mem;
> struct ttm_resource_manager *gtt_man =
> &adev->mman.gtt_mgr.manager;
> +   struct ttm_resource_manager *vram_man =
> +   &adev->mman.vram_mgr.manager;
>
> memset(&mem, 0, sizeof(mem));
> mem.vram.total_heap_size = adev->gmc.real_vram_size;
> @@ -724,7 +726,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
> struct drm_file *filp)
> atomic64_read(&adev->vram_pin_size) -
> AMDGPU_VM_RESERVED_VRAM;
> mem.vram.heap_usage =
> -   amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
> +   ttm_resource_manager_usage(vram_man);
> mem.vram.max_allocation = mem.vram.usable_heap_size * 3 / 4;
>
> mem.cpu_accessible_vram.total_heap_size =
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index d178fbec7048..5859ed0552a4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1884,7 +1884,7 @@ void amdgpu_ttm_set_buffer_funcs_status(struct 
> amdgpu_device *adev, bool enable)
> size = adev->gmc.real_vram_size;
> else
> size = adev->gmc.visible_vram_size;
> -   man->size = size >> PAGE_SHIFT;
> +   man->size = size;
> adev->mman.buffer_funcs_enabled = enable;
>  }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> index 120b69ec9885..cbee84a77331 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> @@ -44,7 +44,6 @@ struct amdgpu_vram_mgr {
> spinlock_t lock;
> struct list_head reservations_pending;
> struct list_head reserved_pages;
> -   atomic64_t usage;
> atomic64_t vis_usage;
>  };
>
> @@ -127,7 +126,6 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
>  void amdgpu_vram_mgr_free_sgt(struct device *dev,
>   enum dma_data_direction dir,
>   struct sg_table *sgt);
> -uint64_t amdgpu_vram_mgr_usage(struct amdgpu_vram_mgr *mgr);
>  uint64_t amdgpu_vram_mgr_vis_usage(struct amdgpu_vram_mgr *mgr);
>  int amdgpu_vram_mgr_reserve_range(struct amdgpu_vram_mgr *mgr,
>   uint64_t start, uint64_t size);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c

[PATCH v5 03/23] drm/rockchip: dw_hdmi: rename vpll clock to reference clock

[Sascha Hauer]

"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
To fix that, this patch renames the vpll clock to ref clock. The clock
name "vpll" is left for compatibility to old device trees.

Signed-off-by: Sascha Hauer 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 8677c8271678..e352e0404f77 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -69,7 +69,7 @@ struct rockchip_hdmi {
struct regmap *regmap;
struct drm_encoder encoder;
const struct rockchip_hdmi_chip_data *chip_data;
-   struct clk *vpll_clk;
+   struct clk *ref_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
struct phy *phy;
@@ -196,14 +196,17 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->regmap);
}
 
-   hdmi->vpll_clk = devm_clk_get(hdmi->dev, "vpll");
-   if (PTR_ERR(hdmi->vpll_clk) == -ENOENT) {
-   hdmi->vpll_clk = NULL;
-   } else if (PTR_ERR(hdmi->vpll_clk) == -EPROBE_DEFER) {
+   hdmi->ref_clk = devm_clk_get(hdmi->dev, "ref");
+   if (PTR_ERR(hdmi->ref_clk) == -ENOENT)
+   hdmi->ref_clk = devm_clk_get(hdmi->dev, "vpll");
+
+   if (PTR_ERR(hdmi->ref_clk) == -ENOENT) {
+   hdmi->ref_clk = NULL;
+   } else if (PTR_ERR(hdmi->ref_clk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
-   } else if (IS_ERR(hdmi->vpll_clk)) {
-   DRM_DEV_ERROR(hdmi->dev, "failed to get vpll clock\n");
-   return PTR_ERR(hdmi->vpll_clk);
+   } else if (IS_ERR(hdmi->ref_clk)) {
+   DRM_DEV_ERROR(hdmi->dev, "failed to get reference clock\n");
+   return PTR_ERR(hdmi->ref_clk);
}
 
hdmi->grf_clk = devm_clk_get(hdmi->dev, "grf");
@@ -257,7 +260,7 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct 
drm_encoder *encoder,
 {
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
 
-   clk_set_rate(hdmi->vpll_clk, adj_mode->clock * 1000);
+   clk_set_rate(hdmi->ref_clk, adj_mode->clock * 1000);
 }
 
 static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
@@ -537,9 +540,9 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
return ret;
}
 
-   ret = clk_prepare_enable(hdmi->vpll_clk);
+   ret = clk_prepare_enable(hdmi->ref_clk);
if (ret) {
-   DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
+   DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI reference 
clock: %d\n",
  ret);
return ret;
}
@@ -558,7 +561,7 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
if (IS_ERR(hdmi->hdmi)) {
ret = PTR_ERR(hdmi->hdmi);
drm_encoder_cleanup(encoder);
-   clk_disable_unprepare(hdmi->vpll_clk);
+   clk_disable_unprepare(hdmi->ref_clk);
}
 
return ret;
@@ -570,7 +573,7 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, 
struct device *master,
struct rockchip_hdmi *hdmi = dev_get_drvdata(dev);
 
dw_hdmi_unbind(hdmi->hdmi);
-   clk_disable_unprepare(hdmi->vpll_clk);
+   clk_disable_unprepare(hdmi->ref_clk);
 }
 
 static const struct component_ops dw_hdmi_rockchip_ops = {
-- 
2.30.2

[PATCH v5 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

This is v5 of adding RK356x VOP2 support. I've dropped the patches that
Heiko already applied, for testing either apply to linux-next or pick
the missing clk patches from v4.

I consider this series being ready for primetime now. One problem might
be patch 1 [drm/encoder: Add of_graph port to struct drm_encoder] to
which I need an ack from Dave and/or Daniel I guess.

I collected the Acks from Rob I got so far. [dt-bindings: display:
rockchip: Add binding for VOP2] doesn't have an ack yet, but it should
be ready now in v5.

Sascha

Changes since v4:
- Reorder patches in a way that binding/dts/driver patches are closer together
- Drop clk patches already applied by Heiko

Changes since v3:
- added changelog to each patch
- Add 4k support to hdmi driver
- rebase on v5.17-rc1

Changes since v2:
- Add pin names to HDMI supply pin description
- Add hclk support to HDMI driver
- Dual license rockchip-vop2 binding, update binding
- Add HDMI connector to board dts files
- drop unnecessary gamma_lut registers from vop2
- Update dclk_vop[012] clock handling, no longer hacks needed
- Complete regmap conversion

Changes since v1:
- drop all unnecessary waiting for frames within atomic modeset and plane update
- Cluster subwin support removed
- gamma support removed
- unnecessary irq_lock removed
- interrupt handling simplified
- simplified zpos handling
- drop is_alpha_support(), use fb->format->has_alpha instead
- use devm_regulator_get() rather than devm_regulator_get_optional() for hdmi 
regulators
- Use fixed number of planes per video port
- Drop homegrown regmap code from vop2 driver (not complete yet)
- Add separate include file for vop2 driver to not pollute the vop include

Andy Yan (1):
  drm: rockchip: Add VOP2 driver

Benjamin Gaignard (1):
  dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568
HDMI

Douglas Anderson (2):
  drm/rockchip: dw_hdmi: Use auto-generated tables
  drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

Michael Riesch (1):
  arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a

Nickey Yang (1):
  drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz

Sascha Hauer (17):
  drm/encoder: Add of_graph port to struct drm_encoder
  drm/rockchip: dw_hdmi: Do not leave clock enabled in error case
  drm/rockchip: dw_hdmi: rename vpll clock to reference clock
  dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name
  arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'
  drm/rockchip: dw_hdmi: add rk3568 support
  drm/rockchip: dw_hdmi: add regulator support
  dt-bindings: display: rockchip: dw-hdmi: Add regulator support
  drm/rockchip: dw_hdmi: Add support for hclk
  dt-bindings: display: rockchip: dw-hdmi: Add additional clock
  drm/rockchip: dw_hdmi: drop mode_valid hook
  dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional
  arm64: dts: rockchip: rk356x: Add VOP2 nodes
  arm64: dts: rockchip: rk356x: Add HDMI nodes
  arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi
  drm/rockchip: Make VOP driver optional
  dt-bindings: display: rockchip: Add binding for VOP2

 .../display/rockchip/rockchip,dw-hdmi.yaml|   29 +-
 .../display/rockchip/rockchip-vop2.yaml   |  140 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi  |2 +-
 .../boot/dts/rockchip/rk3566-quartz64-a.dts   |   48 +
 arch/arm64/boot/dts/rockchip/rk3566.dtsi  |4 +
 .../boot/dts/rockchip/rk3568-evb1-v10.dts |   48 +
 arch/arm64/boot/dts/rockchip/rk3568.dtsi  |4 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi  |   86 +
 drivers/gpu/drm/rockchip/Kconfig  |   14 +
 drivers/gpu/drm/rockchip/Makefile |4 +-
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c   |  293 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |3 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |7 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|2 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |   15 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c  | 2689 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h  |  480 +++
 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c  |  285 ++
 include/drm/drm_encoder.h |2 +
 include/dt-bindings/soc/rockchip,vop2.h   |   14 +
 20 files changed, 4045 insertions(+), 124 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
 create mode 100644 include/dt-bindings/soc/rockchip,vop2.h

-- 
2.30.2

[PATCH v5 10/23] drm/rockchip: dw_hdmi: Add support for hclk

[Sascha Hauer]

The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.

Signed-off-by: Sascha Hauer 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 3d7c3f6fdf22..b9928e622adf 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -76,6 +76,7 @@ struct rockchip_hdmi {
const struct rockchip_hdmi_chip_data *chip_data;
struct clk *ref_clk;
struct clk *grf_clk;
+   struct clk *hclk_clk;
struct dw_hdmi *hdmi;
struct regulator *avdd_0v9;
struct regulator *avdd_1v8;
@@ -226,6 +227,16 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
 
+   hdmi->hclk_clk = devm_clk_get(hdmi->dev, "hclk");
+   if (PTR_ERR(hdmi->hclk_clk) == -ENOENT) {
+   hdmi->hclk_clk = NULL;
+   } else if (PTR_ERR(hdmi->hclk_clk) == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (IS_ERR(hdmi->hclk_clk)) {
+   DRM_DEV_ERROR(hdmi->dev, "failed to get hclk_clk clock\n");
+   return PTR_ERR(hdmi->hclk_clk);
+   }
+
hdmi->avdd_0v9 = devm_regulator_get(hdmi->dev, "avdd-0v9");
if (IS_ERR(hdmi->avdd_0v9))
return PTR_ERR(hdmi->avdd_0v9);
@@ -593,6 +604,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
goto err_clk;
}
 
+   ret = clk_prepare_enable(hdmi->hclk_clk);
+   if (ret) {
+   DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI hclk clock: 
%d\n",
+ ret);
+   goto err_clk;
+   }
+
if (hdmi->chip_data == &rk3568_chip_data) {
regmap_write(hdmi->regmap, RK3568_GRF_VO_CON1,
 HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK |
-- 
2.30.2

[PATCH v5 05/23] arm64: dts: rockchip: rk3399: rename HDMI ref clock to 'ref'

[Sascha Hauer]

The reference clock for the HDMI controller has been renamed to 'ref',
the previous 'vpll' name is only left for compatibility in the driver.
Rename the clock to the new name.

Signed-off-by: Sascha Hauer 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 080457a68e3c..d0add619b0d2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1884,7 +1884,7 @@ hdmi: hdmi@ff94 {
 <&cru SCLK_HDMI_CEC>,
 <&cru PCLK_VIO_GRF>,
 <&cru PLL_VPLL>;
-   clock-names = "iahb", "isfr", "cec", "grf", "vpll";
+   clock-names = "iahb", "isfr", "cec", "grf", "ref";
power-domains = <&power RK3399_PD_HDCP>;
reg-io-width = <4>;
rockchip,grf = <&grf>;
-- 
2.30.2

[PATCH v5 02/23] drm/rockchip: dw_hdmi: Do not leave clock enabled in error case

[Sascha Hauer]

The driver returns an error when devm_phy_optional_get() fails leaving
the previously enabled clock turned on. Change order and enable the
clock only after the phy has been acquired.

Signed-off-by: Sascha Hauer 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 830bdd5e9b7c..8677c8271678 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -529,13 +529,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
-   ret = clk_prepare_enable(hdmi->vpll_clk);
-   if (ret) {
-   DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
- ret);
-   return ret;
-   }
-
hdmi->phy = devm_phy_optional_get(dev, "hdmi");
if (IS_ERR(hdmi->phy)) {
ret = PTR_ERR(hdmi->phy);
@@ -544,6 +537,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
+   ret = clk_prepare_enable(hdmi->vpll_clk);
+   if (ret) {
+   DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
+ ret);
+   return ret;
+   }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
 
-- 
2.30.2

[PATCH v5 06/23] drm/rockchip: dw_hdmi: add rk3568 support

[Sascha Hauer]

Add a new dw_hdmi_plat_data struct and new compatible for rk3568.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Sascha Hauer 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 31 +
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index e352e0404f77..262eef614cb1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -50,6 +50,10 @@
 #define RK3399_GRF_SOC_CON20   0x6250
 #define RK3399_HDMI_LCDC_SEL   BIT(6)
 
+#define RK3568_GRF_VO_CON1 0x0364
+#define RK3568_HDMI_SDAIN_MSK  BIT(15)
+#define RK3568_HDMI_SCLIN_MSK  BIT(14)
+
 #define HIWORD_UPDATE(val, mask)   (val | (mask) << 16)
 
 /**
@@ -470,6 +474,19 @@ static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data 
= {
.use_drm_infoframe = true,
 };
 
+static struct rockchip_hdmi_chip_data rk3568_chip_data = {
+   .lcdsel_grf_reg = -1,
+};
+
+static const struct dw_hdmi_plat_data rk3568_hdmi_drv_data = {
+   .mode_valid = dw_hdmi_rockchip_mode_valid,
+   .mpll_cfg   = rockchip_mpll_cfg,
+   .cur_ctr= rockchip_cur_ctr,
+   .phy_config = rockchip_phy_config,
+   .phy_data = &rk3568_chip_data,
+   .use_drm_infoframe = true,
+};
+
 static const struct of_device_id dw_hdmi_rockchip_dt_ids[] = {
{ .compatible = "rockchip,rk3228-dw-hdmi",
  .data = &rk3228_hdmi_drv_data
@@ -483,6 +500,9 @@ static const struct of_device_id dw_hdmi_rockchip_dt_ids[] 
= {
{ .compatible = "rockchip,rk3399-dw-hdmi",
  .data = &rk3399_hdmi_drv_data
},
+   { .compatible = "rockchip,rk3568-dw-hdmi",
+ .data = &rk3568_hdmi_drv_data
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, dw_hdmi_rockchip_dt_ids);
@@ -517,6 +537,9 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct 
device *master,
encoder = &hdmi->encoder;
 
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+
+   encoder->port = of_graph_get_port_by_id(dev->of_node, 0);
+
/*
 * If we failed to find the CRTC(s) which this encoder is
 * supposed to be connected to, it's because the CRTC has
@@ -547,6 +570,14 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
+   if (hdmi->chip_data == &rk3568_chip_data) {
+   regmap_write(hdmi->regmap, RK3568_GRF_VO_CON1,
+HIWORD_UPDATE(RK3568_HDMI_SDAIN_MSK |
+  RK3568_HDMI_SCLIN_MSK,
+  RK3568_HDMI_SDAIN_MSK |
+  RK3568_HDMI_SCLIN_MSK));
+   }
+
drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
 
-- 
2.30.2

[PATCH v5 16/23] dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optional

[Sascha Hauer]

None of the upstream device tree files has a "unwedge" pinctrl
specified. Make it optional.

Signed-off-by: Sascha Hauer 
Acked-by: Rob Herring 
---

Notes:
Changes since v4:
- Add Robs Ack

 .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 67a76f51637a..7dd753630b46 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -94,6 +94,7 @@ properties:
   The unwedge pinctrl entry shall drive the DDC SDA line low. This is
   intended to work around a hardware errata that can cause the DDC I2C
   bus to be wedged.
+minItems: 1
 items:
   - const: default
   - const: unwedge
-- 
2.30.2

[PATCH v5 21/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

With upcoming VOP2 support VOP won't be the only choice anymore, so make
the VOP driver optional.

Signed-off-by: Sascha Hauer 
---
 drivers/gpu/drm/rockchip/Kconfig| 8 
 drivers/gpu/drm/rockchip/Makefile   | 3 ++-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 9f1ecefc3933..b9b156308460 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -21,8 +21,16 @@ config DRM_ROCKCHIP
 
 if DRM_ROCKCHIP
 
+config ROCKCHIP_VOP
+   bool "Rockchip VOP driver"
+   default y
+   help
+ This selects support for the VOP driver. You should enable it
+ on all older SoCs up to RK3399.
+
 config ROCKCHIP_ANALOGIX_DP
bool "Rockchip specific extensions for Analogix DP driver"
+   depends on ROCKCHIP_VOP
help
  This selects support for Rockchip SoC specific extensions
  for the Analogix Core DP driver. If you want to enable DP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 1a56f696558c..dfc5512fdb9f 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -4,8 +4,9 @@
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
-   rockchip_drm_gem.o rockchip_drm_vop.o rockchip_vop_reg.o
+   rockchip_drm_gem.o
 
+rockchipdrm-$(CONFIG_ROCKCHIP_VOP) += rockchip_drm_vop.o rockchip_vop_reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index bec207de4544..82c8faf1fb6b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -458,7 +458,7 @@ static int __init rockchip_drm_init(void)
int ret;
 
num_rockchip_sub_drivers = 0;
-   ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP);
+   ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_ROCKCHIP_VOP);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver,
CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
-- 
2.30.2

[PATCH v5 07/23] dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMI

[Sascha Hauer]

From: Benjamin Gaignard 

Define a new compatible for rk3568 HDMI.
This version of HDMI hardware block needs two new clocks hclk_vio and hclk
to provide phy reference clocks.

Signed-off-by: Benjamin Gaignard 
Reviewed-by: Rob Herring 
Signed-off-by: Sascha Hauer 
---
 .../devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 0400f67e5f2c..e6b8437a1e2d 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -23,6 +23,7 @@ properties:
   - rockchip,rk3288-dw-hdmi
   - rockchip,rk3328-dw-hdmi
   - rockchip,rk3399-dw-hdmi
+  - rockchip,rk3568-dw-hdmi
 
   reg-io-width:
 const: 4
-- 
2.30.2

[PATCH v5 17/23] arm64: dts: rockchip: rk356x: Add VOP2 nodes

[Sascha Hauer]

The VOP2 is the display output controller on the RK3568. Add the node
for it to the dtsi file along with the required display-subsystem node
and the iommu node.

Signed-off-by: Sascha Hauer 
Acked-by: Rob Herring 
---

Notes:
Changes since v4:
- Add Robs Ack

Changes since v3:
- Bring back gamma_lut regs
- Drop redundant _vop suffix from clock names

 arch/arm64/boot/dts/rockchip/rk3566.dtsi |  4 ++
 arch/arm64/boot/dts/rockchip/rk3568.dtsi |  4 ++
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 51 
 include/dt-bindings/soc/rockchip,vop2.h  | 14 +++
 4 files changed, 73 insertions(+)
 create mode 100644 include/dt-bindings/soc/rockchip,vop2.h

diff --git a/arch/arm64/boot/dts/rockchip/rk3566.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3566.dtsi
index 3839eef5e4f7..595fa2562cb8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3566.dtsi
@@ -18,3 +18,7 @@ power-domain@RK3568_PD_PIPE {
#power-domain-cells = <0>;
};
 };
+
+&vop {
+   compatible = "rockchip,rk3566-vop";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
index 2fd313a295f8..1e55efb6fcfd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
@@ -95,3 +95,7 @@ power-domain@RK3568_PD_PIPE {
#power-domain-cells = <0>;
};
 };
+
+&vop {
+   compatible = "rockchip,rk3568-vop";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi 
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index a68033a23975..4008bd666d01 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 / {
@@ -129,6 +130,11 @@ opp-18 {
};
};
 
+   display_subsystem: display-subsystem {
+   compatible = "rockchip,display-subsystem";
+   ports = <&vop_out>;
+   };
+
firmware {
scmi: scmi {
compatible = "arm,scmi-smc";
@@ -451,6 +457,51 @@ gmac1_mtl_tx_setup: tx-queues-config {
};
};
 
+   vop: vop@fe04 {
+   reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;
+   reg-names = "regs", "gamma_lut";
+   interrupts = ;
+   clocks = <&cru ACLK_VOP>, <&cru HCLK_VOP>, <&cru DCLK_VOP0>, 
<&cru DCLK_VOP1>, <&cru DCLK_VOP2>;
+   clock-names = "aclk", "hclk", "dclk_vp0", "dclk_vp1", 
"dclk_vp2";
+   iommus = <&vop_mmu>;
+   power-domains = <&power RK3568_PD_VO>;
+   rockchip,grf = <&grf>;
+   status = "disabled";
+
+   vop_out: ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   vp0: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   vp1: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   vp2: port@2 {
+   reg = <2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+   };
+
+   vop_mmu: iommu@fe043e00 {
+   compatible = "rockchip,rk3568-iommu";
+   reg = <0x0 0xfe043e00 0x0 0x100>, <0x0 0xfe043f00 0x0 0x100>;
+   interrupts = ;
+   clocks = <&cru ACLK_VOP>, <&cru HCLK_VOP>;
+   clock-names = "aclk", "iface";
+   #iommu-cells = <0>;
+   status = "disabled";
+   };
+
qos_gpu: qos@fe128000 {
compatible = "rockchip,rk3568-qos", "syscon";
reg = <0x0 0xfe128000 0x0 0x20>;
diff --git a/include/dt-bindings/soc/rockchip,vop2.h 
b/include/dt-bindings/soc/rockchip,vop2.h
new file mode 100644
index ..0a87bc90564a
--- /dev/null
+++ b/include/dt-bindings/soc/rockchip,vop2.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
+
+#ifndef __DT_BINDINGS_ROCKCHIP_VOP2_H
+#define __DT_BINDINGS_ROCKCHIP_VOP2_H
+
+#define RK3568_VOP2_EP_RGB 0
+#define RK3568_VOP2_EP_HDMI1
+#define RK3568_VOP2_EP_EDP 2
+#define RK3568_VOP2_EP_MIPI0   3
+#define RK3568_VOP2_EP_LVDS0   4
+#define RK3568_VOP2_EP_MIPI1   5
+#define RK3568_VOP2_EP_LVDS1   6
+
+#endif /* __DT_BINDINGS_ROCKCHIP_VOP2_H */
-- 
2.30.2

[PATCH v5 19/23] arm64: dts: rockchip: rk3568-evb: Enable VOP2 and hdmi

[Sascha Hauer]

This enabled the VOP2 display controller along with hdmi and the
required port routes which is enough to get a picture out of the
hdmi port of the board.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v4:
- Sort nodes alphabetically

Changes since v3:
- Fix HDMI connector type

 .../boot/dts/rockchip/rk3568-evb1-v10.dts | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts 
b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
index 184e2aa2416a..18f0f5abddcf 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dts
@@ -7,6 +7,7 @@
 /dts-v1/;
 #include 
 #include 
+#include 
 #include "rk3568.dtsi"
 
 / {
@@ -33,6 +34,17 @@ dc_12v: dc-12v {
regulator-max-microvolt = <1200>;
};
 
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
vcc3v3_sys: vcc3v3-sys {
compatible = "regulator-fixed";
regulator-name = "vcc3v3_sys";
@@ -106,6 +118,25 @@ &gmac1m1_rgmii_clk
status = "okay";
 };
 
+&hdmi {
+   avdd-0v9-supply = <&vdda0v9_image>;
+   avdd-1v8-supply = <&vcca1v8_image>;
+   status = "okay";
+};
+
+&hdmi_in {
+   hdmi_in_vp0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&vp0_out_hdmi>;
+   };
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &i2c0 {
status = "okay";
 
@@ -390,3 +421,20 @@ &sdmmc0 {
 &uart2 {
status = "okay";
 };
+
+&vop {
+   assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+   assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+   status = "okay";
+};
+
+&vop_mmu {
+   status = "okay";
+};
+
+&vp0 {
+   vp0_out_hdmi: endpoint@RK3568_VOP2_EP_HDMI {
+   reg = ;
+   remote-endpoint = <&hdmi_in_vp0>;
+   };
+};
-- 
2.30.2

[PATCH v5 04/23] dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock name

[Sascha Hauer]

"vpll" is a misnomer. A clock input to a device should be named after
the usage in the device, not after the clock that drives it. On the
rk3568 the same clock is driven by the HPLL.
This patch adds "ref" as a new alternative clock name for "vpll"

Signed-off-by: Sascha Hauer 
Acked-by: Rob Herring 
---

Notes:
Changes since v4:
- Add Robs Ack

Changes since v3:
- Keep old clock name for compatibility reasons

 .../bindings/display/rockchip/rockchip,dw-hdmi.yaml  | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index da3b889ad8fc..0400f67e5f2c 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -36,7 +36,8 @@ properties:
   # order when present.
   - description: The HDMI CEC controller main clock
   - description: Power for GRF IO
-  - description: External clock for some HDMI PHY
+  - description: External clock for some HDMI PHY (old clock name, 
deprecated)
+  - description: External clock for some HDMI PHY (new name)
 
   clock-names:
 minItems: 2
@@ -47,10 +48,14 @@ properties:
   - cec
   - grf
   - vpll
+  - ref
   - enum:
   - grf
   - vpll
-  - const: vpll
+  - ref
+  - enum:
+  - vpll
+  - ref
 
   ddc-i2c-bus:
 $ref: /schemas/types.yaml#/definitions/phandle
-- 
2.30.2

[PATCH v5 01/23] drm/encoder: Add of_graph port to struct drm_encoder

[Sascha Hauer]

Add a device node to drm_encoder which corresponds with the port node
in the DT description of the encoder. This allows drivers to find the
of_graph link between a crtc and an encoder.

Signed-off-by: Sascha Hauer 
---
 include/drm/drm_encoder.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
index 6e91a0280f31..3acd054b1eb3 100644
--- a/include/drm/drm_encoder.h
+++ b/include/drm/drm_encoder.h
@@ -99,6 +99,8 @@ struct drm_encoder {
struct drm_device *dev;
struct list_head head;
 
+   struct device_node *port;
+
struct drm_mode_object base;
char *name;
/**
-- 
2.30.2

[PATCH v5 20/23] arm64: dts: rockchip: enable vop2 and hdmi tx on quartz64a

[Sascha Hauer]

From: Michael Riesch 

Enable the RK356x Video Output Processor (VOP) 2 on the Pine64
Quartz64 Model A.

Signed-off-by: Michael Riesch 
Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v4:
- Sort nodes alphabetically

Changes since v3:
- Fix HDMI connector type

 .../boot/dts/rockchip/rk3566-quartz64-a.dts   | 48 +++
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts 
b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
index 166399b7f13f..1501f4c3722a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 #include "rk3566.dtsi"
 
 / {
@@ -35,6 +36,17 @@ fan: gpio_fan {
#cooling-cells = <2>;
};
 
+   hdmi-con {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <&hdmi_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -205,6 +217,25 @@ &gmac1m0_clkinout
status = "okay";
 };
 
+&hdmi {
+   avdd-0v9-supply = <&vdda_0v9>;
+   avdd-1v8-supply = <&vcc_1v8>;
+   status = "okay";
+};
+
+&hdmi_in {
+   hdmi_in_vp0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&vp0_out_hdmi>;
+   };
+};
+
+&hdmi_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <&hdmi_con_in>;
+   };
+};
+
 &i2c0 {
status = "okay";
 
@@ -551,3 +582,20 @@ bluetooth {
 &uart2 {
status = "okay";
 };
+
+&vop {
+   assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+   assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+   status = "okay";
+};
+
+&vop_mmu {
+   status = "okay";
+};
+
+&vp0 {
+   vp0_out_hdmi: endpoint@RK3568_VOP2_EP_HDMI {
+   reg = ;
+   remote-endpoint = <&hdmi_in_vp0>;
+   };
+};
-- 
2.30.2

[PATCH v5 11/23] dt-bindings: display: rockchip: dw-hdmi: Add additional clock

[Sascha Hauer]

The rk3568 HDMI has an additional clock that needs to be enabled for the
HDMI controller to work. The purpose of that clock is not clear. It is
named "hclk" in the downstream driver, so use the same name.

Signed-off-by: Sascha Hauer 
Acked-by: Rob Herring 
---

Notes:
Changes since v4:
- Add Robs Ack

 .../bindings/display/rockchip/rockchip,dw-hdmi.yaml| 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index 38ebb6983028..67a76f51637a 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -44,12 +44,13 @@ properties:
 items:
   - {}
   - {}
-  # The next three clocks are all optional, but shall be specified in this
+  # The next four clocks are all optional, but shall be specified in this
   # order when present.
   - description: The HDMI CEC controller main clock
   - description: Power for GRF IO
   - description: External clock for some HDMI PHY (old clock name, 
deprecated)
   - description: External clock for some HDMI PHY (new name)
+  - description: hclk
 
   clock-names:
 minItems: 2
@@ -61,13 +62,17 @@ properties:
   - grf
   - vpll
   - ref
+  - hclk
   - enum:
   - grf
   - vpll
   - ref
+  - hclk
   - enum:
   - vpll
   - ref
+  - hclk
+  - const: hclk
 
   ddc-i2c-bus:
 $ref: /schemas/types.yaml#/definitions/phandle
-- 
2.30.2

[PATCH v5 15/23] drm/rockchip: dw_hdmi: add default 594Mhz clk for 4K@60hz

[Sascha Hauer]

From: Nickey Yang 

add 594Mhz configuration parameters in rockchip_phy_config

Signed-off-by: Nickey Yang 
Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v3:
- new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 77f82a4fd027..c038674271b2 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -187,6 +187,7 @@ static const struct dw_hdmi_phy_config 
rockchip_phy_config[] = {
{ 7425,  0x8009, 0x0004, 0x0272},
{ 14850, 0x802b, 0x0004, 0x028d},
{ 29700, 0x8039, 0x0005, 0x028d},
+   { 59400, 0x8039, 0x, 0x019d},
{ ~0UL,  0x, 0x, 0x}
 };
 
-- 
2.30.2

[PATCH v5 12/23] drm/rockchip: dw_hdmi: Use auto-generated tables

[Sascha Hauer]

From: Douglas Anderson 

The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor.  Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (not that we use those anyway).  It was also always a lot of
extra work every time we wanted to add a new clock rate since we had
to cross-reference several tables.

In  I've gone through the work to figure
out how to generate this table automatically.  Let's now use the
automatically generated table and then we'll never need to look at it
again.

We only support 8-bit mode right now and only support a small number
of clock rates and and I've verified that the only 8-bit rate that was
affected was 148.5.  That mode appears to have been wrong in the old
table.

Signed-off-by: Douglas Anderson 
Signed-off-by: Yakir Yang 
---

Notes:
Changes since v3:
- new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +++-
 1 file changed, 69 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index b9928e622adf..160107b333ef 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -87,80 +87,88 @@ struct rockchip_hdmi {
 
 static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
{
-   2700, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   30666000, {
+   { 0x00b3, 0x },
+   { 0x2153, 0x },
+   { 0x40f3, 0x },
},
-   }, {
-   3600, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   },  {
+   3680, {
+   { 0x00b3, 0x },
+   { 0x2153, 0x },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   4000, {
-   { 0x00b3, 0x},
-   { 0x2153, 0x},
-   { 0x40f3, 0x}
+   },  {
+   4600, {
+   { 0x00b3, 0x },
+   { 0x2142, 0x0001 },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   5400, {
-   { 0x0072, 0x0001},
-   { 0x2142, 0x0001},
-   { 0x40a2, 0x0001},
+   },  {
+   61333000, {
+   { 0x0072, 0x0001 },
+   { 0x2142, 0x0001 },
+   { 0x40a2, 0x0001 },
},
-   }, {
-   6500, {
-   { 0x0072, 0x0001},
-   { 0x2142, 0x0001},
-   { 0x40a2, 0x0001},
+   },  {
+   7360, {
+   { 0x0072, 0x0001 },
+   { 0x2142, 0x0001 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   6600, {
-   { 0x013e, 0x0003},
-   { 0x217e, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   9200, {
+   { 0x0072, 0x0001 },
+   { 0x2145, 0x0002 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   7425, {
-   { 0x0072, 0x0001},
-   { 0x2145, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   122666000, {
+   { 0x0051, 0x0002 },
+   { 0x2145, 0x0002 },
+   { 0x4061, 0x0002 },
},
-   }, {
-   8350, {
-   { 0x0072, 0x0001},
+   },  {
+   14720, {
+   { 0x0051, 0x0002 },
+   { 0x2145, 0x0002 },
+   { 0x4064, 0x0003 },
},
-   }, {
-   10800, {
-   { 0x0051, 0x0002},
-   { 0x2145, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   18400, {
+   { 0x0051, 0x0002 },
+   { 0x214c, 0x0003 },
+   { 0x4064, 0x0003 },
},
-   }, {
-   10650, {
-   { 0x0051, 0x0002},
-   { 0x2145, 0x0002},
-   { 0x4061, 0x0002}
+   },  {
+   22000, {
+   { 0x0040, 0x0003 },
+   { 0x214c, 0x0003 },
+   { 0x4064, 0x0003 },
   

[PATCH v5 22/23] drm: rockchip: Add VOP2 driver

[Sascha Hauer]

From: Andy Yan 

The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568.
It replaces the VOP unit found in the older Rockchip SoCs.

This driver has been derived from the downstream Rockchip Kernel and
heavily modified:

- All nonstandard DRM properties have been removed
- dropped struct vop2_plane_state and pass around less data between
  functions
- Dropped all DRM_FORMAT_* not known on upstream
- rework register access to get rid of excessively used macros
- Drop all waiting for framesyncs

The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB
board. Overlay support is tested with the modetest utility. AFBC support
on the cluster windows is tested with weston-simple-dmabuf-egl on
weston using the (yet to be upstreamed) panfrost driver support.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v4:
- Avoid stack frame overflow by not allocating big array on the stack

Changes since v3:
- Sort includes
- fix typos
- Drop spinlock
- Use regmap_set_bits()/regmap_clear_bits()
- simplify vop2_scale_factor()
- simplify vop2_afbc_transform_offset()

 drivers/gpu/drm/rockchip/Kconfig |6 +
 drivers/gpu/drm/rockchip/Makefile|1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |1 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h  |7 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c   |2 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h  |   15 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2689 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h |  480 
 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c |  285 ++
 9 files changed, 3485 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop2_reg.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index b9b156308460..4ff0043f0ee7 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -28,6 +28,12 @@ config ROCKCHIP_VOP
  This selects support for the VOP driver. You should enable it
  on all older SoCs up to RK3399.
 
+config ROCKCHIP_VOP2
+   bool "Rockchip VOP2 driver"
+   help
+ This selects support for the VOP2 driver. You should enable it
+ on all newer SoCs beginning form RK3568.
+
 config ROCKCHIP_ANALOGIX_DP
bool "Rockchip specific extensions for Analogix DP driver"
depends on ROCKCHIP_VOP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index dfc5512fdb9f..3ff7b21c0414 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,6 +6,7 @@
 rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
rockchip_drm_gem.o
 
+rockchipdrm-$(CONFIG_ROCKCHIP_VOP2) += rockchip_drm_vop2.o rockchip_vop2_reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_VOP) += rockchip_drm_vop.o rockchip_vop_reg.o
 rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
 rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 82c8faf1fb6b..95f6c5985fdd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -459,6 +459,7 @@ static int __init rockchip_drm_init(void)
 
num_rockchip_sub_drivers = 0;
ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_ROCKCHIP_VOP);
+   ADD_ROCKCHIP_SUB_DRIVER(vop2_platform_driver, CONFIG_ROCKCHIP_VOP2);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver,
CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 143a48330f84..6e1f97e1e4a6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -18,7 +18,7 @@
 
 #define ROCKCHIP_MAX_FB_BUFFER 3
 #define ROCKCHIP_MAX_CONNECTOR 2
-#define ROCKCHIP_MAX_CRTC  2
+#define ROCKCHIP_MAX_CRTC  4
 
 struct drm_device;
 struct drm_connector;
@@ -31,6 +31,9 @@ struct rockchip_crtc_state {
int output_bpc;
int output_flags;
bool enable_afbc;
+   uint32_t bus_format;
+   u32 bus_flags;
+   int color_space;
 };
 #define to_rockchip_crtc_state(s) \
container_of(s, struct rockchip_crtc_state, base)
@@ -63,4 +66,6 @@ extern struct platform_driver rockchip_dp_driver;
 extern struct platform_driver rockchip_lvds_driver;
 extern struct platform_driver vop_platform_driver;
 extern struct platform_driver rk3066_hdmi_driver;
+extern struct platform_driver vop2_platform_driver;
+
 #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/ro

[PATCH v5 14/23] drm/rockchip: dw_hdmi: Set cur_ctr to 0 always

[Sascha Hauer]

From: Douglas Anderson 

Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL.  In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin.  We believe that
lowering the bandwidth like this is safe given sufficient testing.

Signed-off-by: Douglas Anderson 
Signed-off-by: Yakir Yang 
Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v3:
- new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index c44eb4d2e2d5..77f82a4fd027 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -176,20 +176,8 @@ static const struct dw_hdmi_mpll_config 
rockchip_mpll_cfg[] = {
 static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
/*  pixelclkbpp8bpp10   bpp12 */
{
-   4000,  { 0x0018, 0x0018, 0x0018 },
-   }, {
-   6500,  { 0x0028, 0x0028, 0x0028 },
-   }, {
-   6600,  { 0x0038, 0x0038, 0x0038 },
-   }, {
-   7425,  { 0x0028, 0x0038, 0x0038 },
-   }, {
-   8350,  { 0x0028, 0x0038, 0x0038 },
-   }, {
-   14625, { 0x0038, 0x0038, 0x0038 },
-   }, {
-   14850, { 0x, 0x0038, 0x0038 },
-   }, {
+   6, { 0x, 0x, 0x },
+   },  {
~0UL,  { 0x, 0x, 0x},
}
 };
-- 
2.30.2

[PATCH v5 08/23] drm/rockchip: dw_hdmi: add regulator support

[Sascha Hauer]

The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed
for the HDMI port. add support for these to the driver for boards which
have them supplied by switchable regulators.

Signed-off-by: Sascha Hauer 
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 41 +++--
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 262eef614cb1..3d7c3f6fdf22 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -76,6 +77,8 @@ struct rockchip_hdmi {
struct clk *ref_clk;
struct clk *grf_clk;
struct dw_hdmi *hdmi;
+   struct regulator *avdd_0v9;
+   struct regulator *avdd_1v8;
struct phy *phy;
 };
 
@@ -223,6 +226,14 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return PTR_ERR(hdmi->grf_clk);
}
 
+   hdmi->avdd_0v9 = devm_regulator_get(hdmi->dev, "avdd-0v9");
+   if (IS_ERR(hdmi->avdd_0v9))
+   return PTR_ERR(hdmi->avdd_0v9);
+
+   hdmi->avdd_1v8 = devm_regulator_get(hdmi->dev, "avdd-1v8");
+   if (IS_ERR(hdmi->avdd_1v8))
+   return PTR_ERR(hdmi->avdd_1v8);
+
return 0;
 }
 
@@ -563,11 +574,23 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
return ret;
}
 
+   ret = regulator_enable(hdmi->avdd_0v9);
+   if (ret) {
+   DRM_DEV_ERROR(hdmi->dev, "failed to enable avdd0v9: %d\n", ret);
+   goto err_avdd_0v9;
+   }
+
+   ret = regulator_enable(hdmi->avdd_1v8);
+   if (ret) {
+   DRM_DEV_ERROR(hdmi->dev, "failed to enable avdd1v8: %d\n", ret);
+   goto err_avdd_1v8;
+   }
+
ret = clk_prepare_enable(hdmi->ref_clk);
if (ret) {
DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI reference 
clock: %d\n",
  ret);
-   return ret;
+   goto err_clk;
}
 
if (hdmi->chip_data == &rk3568_chip_data) {
@@ -591,10 +614,19 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
struct device *master,
 */
if (IS_ERR(hdmi->hdmi)) {
ret = PTR_ERR(hdmi->hdmi);
-   drm_encoder_cleanup(encoder);
-   clk_disable_unprepare(hdmi->ref_clk);
+   goto err_bind;
}
 
+   return 0;
+
+err_bind:
+   clk_disable_unprepare(hdmi->ref_clk);
+   drm_encoder_cleanup(encoder);
+err_clk:
+   regulator_disable(hdmi->avdd_1v8);
+err_avdd_1v8:
+   regulator_disable(hdmi->avdd_0v9);
+err_avdd_0v9:
return ret;
 }
 
@@ -605,6 +637,9 @@ static void dw_hdmi_rockchip_unbind(struct device *dev, 
struct device *master,
 
dw_hdmi_unbind(hdmi->hdmi);
clk_disable_unprepare(hdmi->ref_clk);
+
+   regulator_disable(hdmi->avdd_1v8);
+   regulator_disable(hdmi->avdd_0v9);
 }
 
 static const struct component_ops dw_hdmi_rockchip_ops = {
-- 
2.30.2

[PATCH v5 23/23] dt-bindings: display: rockchip: Add binding for VOP2

[Sascha Hauer]

The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566.
The binding differs slightly from the existing VOP binding, so add a new
binding file for it.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v4:
- Fix clk names in example
- Drop unnecessary assigned-clocks, assigned-clock-rates and 
assigned-clock-parents

Changes since v3:
- drop redundant _vop suffix from clock names

Changes since v3:
- new patch

 .../display/rockchip/rockchip-vop2.yaml   | 140 ++
 1 file changed, 140 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
new file mode 100644
index ..655d9b327f7d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
@@ -0,0 +1,140 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/rockchip/rockchip-vop2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip SoC display controller (VOP2)
+
+description:
+  VOP2 (Video Output Processor v2) is the display controller for the Rockchip
+  series of SoCs which transfers the image data from a video memory
+  buffer to an external LCD interface.
+
+maintainers:
+  - Sandy Huang 
+  - Heiko Stuebner 
+
+properties:
+  compatible:
+enum:
+  - rockchip,rk3566-vop
+  - rockchip,rk3568-vop
+
+  reg:
+minItems: 1
+items:
+  - description:
+  Must contain one entry corresponding to the base address and length
+  of the register space.
+  - description:
+  Can optionally contain a second entry corresponding to
+  the CRTC gamma LUT address.
+
+  interrupts:
+maxItems: 1
+description:
+  The VOP interrupt is shared by several interrupt sources, such as
+  frame start (VSYNC), line flag and other status interrupts.
+
+  clocks:
+items:
+  - description: Clock for ddr buffer transfer.
+  - description: Clock for the ahb bus to R/W the phy regs.
+  - description: Pixel clock for video port 0.
+  - description: Pixel clock for video port 1.
+  - description: Pixel clock for video port 2.
+
+  clock-names:
+items:
+  - const: aclk
+  - const: hclk
+  - const: dclk_vp0
+  - const: dclk_vp1
+  - const: dclk_vp2
+
+  rockchip,grf:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  Phandle to GRF regs used for misc control
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Output endpoint of VP0
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Output endpoint of VP1
+
+  port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  Output endpoint of VP2
+
+  iommus:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+bus {
+#address-cells = <2>;
+#size-cells = <2>;
+vop: vop@fe04 {
+compatible = "rockchip,rk3568-vop";
+reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0 0x1000>;
+interrupts = ;
+clocks = <&cru ACLK_VOP>,
+ <&cru HCLK_VOP>,
+ <&cru DCLK_VOP0>,
+ <&cru DCLK_VOP1>,
+ <&cru DCLK_VOP2>;
+clock-names = "aclk",
+  "hclk",
+  "dclk_vp0",
+  "dclk_vp1",
+  "dclk_vp2";
+power-domains = <&power RK3568_PD_VO>;
+iommus = <&vop_mmu>;
+vop_out: ports {
+#address-cells = <1>;
+#size-cells = <0>;
+vp0: port@0 {
+reg = <0>;
+#address-cells = <1>;
+#size-cells = <0>;
+};
+vp1: port@1 {
+reg = <1>;
+#address-cells = <1>;
+#size-cells = <0>;
+};
+vp2: port@2 {
+reg = <2>;
+#address-cells = <1>;
+#size-cells = <0>;
+};
+};
+};
+};
-- 
2.30.2

[PATCH v5 18/23] arm64: dts: rockchip: rk356x: Add HDMI nodes

[Sascha Hauer]

Add support for the HDMI port found on RK3568.

Signed-off-by: Sascha Hauer 
---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi 
b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 4008bd666d01..e38fb223e9b8 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 / {
@@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
status = "disabled";
};
 
+   hdmi: hdmi@fe0a {
+   compatible = "rockchip,rk3568-dw-hdmi";
+   reg = <0x0 0xfe0a 0x0 0x2>;
+   interrupts = ;
+   clocks = <&cru PCLK_HDMI_HOST>,
+<&cru CLK_HDMI_SFR>,
+<&cru CLK_HDMI_CEC>,
+<&pmucru CLK_HDMI_REF>,
+<&cru HCLK_VOP>;
+   clock-names = "iahb", "isfr", "cec", "ref", "hclk";
+   pinctrl-names = "default";
+   pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
+   power-domains = <&power RK3568_PD_VO>;
+   reg-io-width = <4>;
+   rockchip,grf = <&grf>;
+   #sound-dai-cells = <0>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   hdmi_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   hdmi_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+   };
+   };
+
qos_gpu: qos@fe128000 {
compatible = "rockchip,rk3568-qos", "syscon";
reg = <0x0 0xfe128000 0x0 0x20>;
-- 
2.30.2

[PATCH v5 13/23] drm/rockchip: dw_hdmi: drop mode_valid hook

[Sascha Hauer]

The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. The frequencies in the mpll table are meant as
a frequency range up to which the entry works, not as a frequency that
must match the pixel clock. The downstream Kernel also does not have
this check, so drop it to allow for more display resolutions.

Signed-off-by: Sascha Hauer 
---

Notes:
Changes since v3:
- new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 25 -
 1 file changed, 25 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 160107b333ef..c44eb4d2e2d5 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -256,26 +256,6 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi 
*hdmi)
return 0;
 }
 
-static enum drm_mode_status
-dw_hdmi_rockchip_mode_valid(struct dw_hdmi *hdmi, void *data,
-   const struct drm_display_info *info,
-   const struct drm_display_mode *mode)
-{
-   const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
-   int pclk = mode->clock * 1000;
-   bool valid = false;
-   int i;
-
-   for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
-   if (pclk == mpll_cfg[i].mpixelclock) {
-   valid = true;
-   break;
-   }
-   }
-
-   return (valid) ? MODE_OK : MODE_BAD;
-}
-
 static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
 {
 }
@@ -441,7 +421,6 @@ static struct rockchip_hdmi_chip_data rk3228_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3228_hdmi_drv_data = {
-   .mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
@@ -458,7 +437,6 @@ static struct rockchip_hdmi_chip_data rk3288_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3288_hdmi_drv_data = {
-   .mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg   = rockchip_mpll_cfg,
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
@@ -478,7 +456,6 @@ static struct rockchip_hdmi_chip_data rk3328_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3328_hdmi_drv_data = {
-   .mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg = rockchip_mpll_cfg,
.cur_ctr = rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
@@ -496,7 +473,6 @@ static struct rockchip_hdmi_chip_data rk3399_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3399_hdmi_drv_data = {
-   .mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg   = rockchip_mpll_cfg,
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
@@ -509,7 +485,6 @@ static struct rockchip_hdmi_chip_data rk3568_chip_data = {
 };
 
 static const struct dw_hdmi_plat_data rk3568_hdmi_drv_data = {
-   .mode_valid = dw_hdmi_rockchip_mode_valid,
.mpll_cfg   = rockchip_mpll_cfg,
.cur_ctr= rockchip_cur_ctr,
.phy_config = rockchip_phy_config,
-- 
2.30.2

[PATCH v5 09/23] dt-bindings: display: rockchip: dw-hdmi: Add regulator support

[Sascha Hauer]

The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs
needed for the HDMI port. Add the binding for these supplies.

Signed-off-by: Sascha Hauer 
Acked-by: Rob Herring 
---

Notes:
Changes since v4:
- Add Robs Ack

 .../bindings/display/rockchip/rockchip,dw-hdmi.yaml   | 11 +++
 1 file changed, 11 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
index e6b8437a1e2d..38ebb6983028 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml
@@ -28,6 +28,17 @@ properties:
   reg-io-width:
 const: 4
 
+  avdd-0v9-supply:
+description:
+  A 0.9V supply that powers up the SoC internal circuitry. The actual pin 
name
+  varies between the different SoCs and is usually HDMI_TX_AVDD_0V9 or 
sometimes
+  HDMI_AVDD_1V0.
+
+  avdd-1v8-supply:
+description:
+  A 1.8V supply that powers up the SoC internal circuitry. The pin name on 
the
+  SoC usually is HDMI_TX_AVDD_1V8.
+
   clocks:
 minItems: 2
 items:
-- 
2.30.2

Re: [PATCH v5 02/23] drm/rockchip: dw_hdmi: Do not leave clock enabled in error case

[Heiko Stübner]

Am Mittwoch, 9. Februar 2022, 10:53:29 CET schrieb Sascha Hauer:
> The driver returns an error when devm_phy_optional_get() fails leaving
> the previously enabled clock turned on. Change order and enable the
> clock only after the phy has been acquired.
> 
> Signed-off-by: Sascha Hauer 

just a note for me, already applied to drm-misc-fixes:
https://cgit.freedesktop.org/drm/drm-misc/commit/?h=drm-misc-fixes&id=c0cfbb122275da1b726481de5a8cffeb24e6322b

> ---
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index 830bdd5e9b7c..8677c8271678 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -529,13 +529,6 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
> struct device *master,
>   return ret;
>   }
>  
> - ret = clk_prepare_enable(hdmi->vpll_clk);
> - if (ret) {
> - DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
> -   ret);
> - return ret;
> - }
> -
>   hdmi->phy = devm_phy_optional_get(dev, "hdmi");
>   if (IS_ERR(hdmi->phy)) {
>   ret = PTR_ERR(hdmi->phy);
> @@ -544,6 +537,13 @@ static int dw_hdmi_rockchip_bind(struct device *dev, 
> struct device *master,
>   return ret;
>   }
>  
> + ret = clk_prepare_enable(hdmi->vpll_clk);
> + if (ret) {
> + DRM_DEV_ERROR(hdmi->dev, "Failed to enable HDMI vpll: %d\n",
> +   ret);
> + return ret;
> + }
> +
>   drm_encoder_helper_add(encoder, &dw_hdmi_rockchip_encoder_helper_funcs);
>   drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
>  
> 

Re: [PATCH v5 12/23] drm/rockchip: dw_hdmi: Use auto-generated tables

[Heiko Stübner]

Am Mittwoch, 9. Februar 2022, 10:53:39 CET schrieb Sascha Hauer:
> From: Douglas Anderson 
> 
> The previous tables for mpll_cfg and curr_ctrl were created using the
> 20-pages of example settings provided by the PHY vendor.  Those
> example settings weren't particularly dense, so there were places
> where we were guessing what the settings would be for 10-bit and
> 12-bit (not that we use those anyway).  It was also always a lot of
> extra work every time we wanted to add a new clock rate since we had
> to cross-reference several tables.
> 
> In  I've gone through the work to figure
> out how to generate this table automatically.  Let's now use the
> automatically generated table and then we'll never need to look at it
> again.
> 
> We only support 8-bit mode right now and only support a small number
> of clock rates and and I've verified that the only 8-bit rate that was
> affected was 148.5.  That mode appears to have been wrong in the old
> table.
> 
> Signed-off-by: Douglas Anderson 
> Signed-off-by: Yakir Yang 

missing Signed-off-by: Sascha Hauer <...>

> ---
> 
> Notes:
> Changes since v3:
> - new patch
> 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 130 +++-
>  1 file changed, 69 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
> b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> index b9928e622adf..160107b333ef 100644
> --- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
> @@ -87,80 +87,88 @@ struct rockchip_hdmi {
>  
>  static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
>   {
> - 2700, {
> - { 0x00b3, 0x},
> - { 0x2153, 0x},
> - { 0x40f3, 0x}
> + 30666000, {
> + { 0x00b3, 0x },
> + { 0x2153, 0x },
> + { 0x40f3, 0x },
>   },
> - }, {
> - 3600, {
> - { 0x00b3, 0x},
> - { 0x2153, 0x},
> - { 0x40f3, 0x}
> + },  {
> + 3680, {
> + { 0x00b3, 0x },
> + { 0x2153, 0x },
> + { 0x40a2, 0x0001 },
>   },
> - }, {
> - 4000, {
> - { 0x00b3, 0x},
> - { 0x2153, 0x},
> - { 0x40f3, 0x}
> + },  {
> + 4600, {
> + { 0x00b3, 0x },
> + { 0x2142, 0x0001 },
> + { 0x40a2, 0x0001 },
>   },
> - }, {
> - 5400, {
> - { 0x0072, 0x0001},
> - { 0x2142, 0x0001},
> - { 0x40a2, 0x0001},
> + },  {
> + 61333000, {
> + { 0x0072, 0x0001 },
> + { 0x2142, 0x0001 },
> + { 0x40a2, 0x0001 },
>   },
> - }, {
> - 6500, {
> - { 0x0072, 0x0001},
> - { 0x2142, 0x0001},
> - { 0x40a2, 0x0001},
> + },  {
> + 7360, {
> + { 0x0072, 0x0001 },
> + { 0x2142, 0x0001 },
> + { 0x4061, 0x0002 },
>   },
> - }, {
> - 6600, {
> - { 0x013e, 0x0003},
> - { 0x217e, 0x0002},
> - { 0x4061, 0x0002}
> + },  {
> + 9200, {
> + { 0x0072, 0x0001 },
> + { 0x2145, 0x0002 },
> + { 0x4061, 0x0002 },
>   },
> - }, {
> - 7425, {
> - { 0x0072, 0x0001},
> - { 0x2145, 0x0002},
> - { 0x4061, 0x0002}
> + },  {
> + 122666000, {
> + { 0x0051, 0x0002 },
> + { 0x2145, 0x0002 },
> + { 0x4061, 0x0002 },
>   },
> - }, {
> - 8350, {
> - { 0x0072, 0x0001},
> + },  {
> + 14720, {
> + { 0x0051, 0x0002 },
> + { 0x2145, 0x0002 },
> + { 0x4064, 0x0003 },
>   },
> - }, {
> - 10800, {
> - { 0x0051, 0x0002},
> - { 0x2145, 0x0002},
> - { 0x4061, 0x0002}
> + },  {
> + 18400, {
> + { 0x0051, 0x0002 },
> + { 0x214c, 0x0003 },
> + { 0x4064, 0x0003 },
>   },
> - }, {
> - 10650, {
> - { 0x0051, 0x0002},
> - { 0x2145, 0x0002},
> - { 0x4061, 0x0002}

Re: [PATCH v5 01/23] drm/encoder: Add of_graph port to struct drm_encoder

[Sascha Hauer]

David, Daniel,

I'll need a word from you regarding this patch. It's needed in patch
22/23 in this series.
vop2_crtc_atomic_enable() needs to control the mux which routes the
display output to the different encoders. Which encoder is used is
described in the of_graph port, so I need a way to identify the encoder
in the device tree.

Sascha

On Wed, Feb 09, 2022 at 10:53:28AM +0100, Sascha Hauer wrote:
> Add a device node to drm_encoder which corresponds with the port node
> in the DT description of the encoder. This allows drivers to find the
> of_graph link between a crtc and an encoder.
> 
> Signed-off-by: Sascha Hauer 
> ---
>  include/drm/drm_encoder.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
> index 6e91a0280f31..3acd054b1eb3 100644
> --- a/include/drm/drm_encoder.h
> +++ b/include/drm/drm_encoder.h
> @@ -99,6 +99,8 @@ struct drm_encoder {
>   struct drm_device *dev;
>   struct list_head head;
>  
> + struct device_node *port;
> +
>   struct drm_mode_object base;
>   char *name;
>   /**
> -- 
> 2.30.2
> 
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 2/9] drm/ttm: move the LRU into resource handling v3

[Matthew Auld]

On Wed, 9 Feb 2022 at 08:41, Christian König
 wrote:
>
> This way we finally fix the problem that new resource are
> not immediately evict-able after allocation.
>
> That has caused numerous problems including OOM on GDS handling
> and not being able to use TTM as general resource manager.
>
> v2: stop assuming in ttm_resource_fini that res->bo is still valid.
> v3: cleanup kerneldoc, add more lockdep annotation
>
> Signed-off-by: Christian König 
> Tested-by: Bas Nieuwenhuizen 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |   8 +-
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c |   2 +-
>  drivers/gpu/drm/ttm/ttm_bo.c| 115 ++
>  drivers/gpu/drm/ttm/ttm_bo_util.c   |   1 -
>  drivers/gpu/drm/ttm/ttm_device.c|  64 ++---
>  drivers/gpu/drm/ttm/ttm_resource.c  | 122 +++-
>  include/drm/ttm/ttm_bo_api.h|  16 
>  include/drm/ttm/ttm_bo_driver.h |  29 +-
>  include/drm/ttm/ttm_resource.h  |  35 +++
>  9 files changed, 197 insertions(+), 195 deletions(-)



>  /**
>   * ttm_resource_init - resource object constructure
>   * @bo: buffer object this resources is allocated for
> @@ -52,10 +156,12 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
> res->bus.is_iomem = false;
> res->bus.caching = ttm_cached;
> res->bo = bo;
> +   INIT_LIST_HEAD(&res->lru);
>
> man = ttm_manager_type(bo->bdev, place->mem_type);
> spin_lock(&bo->bdev->lru_lock);
> man->usage += bo->base.size;
> +   ttm_resource_move_to_lru_tail(res, NULL);
> spin_unlock(&bo->bdev->lru_lock);
>  }
>  EXPORT_SYMBOL(ttm_resource_init);
> @@ -66,15 +172,21 @@ EXPORT_SYMBOL(ttm_resource_init);
>   * @res: the resource to clean up
>   *
>   * Should be used by resource manager backends to clean up the TTM resource
> - * objects before freeing the underlying structure. Counterpart of
> - * &ttm_resource_init
> + * objects before freeing the underlying structure. Makes sure the resource 
> is
> + * removed from the LRU before destruction.
> + * Counterpart of &ttm_resource_init.
>   */
>  void ttm_resource_fini(struct ttm_resource_manager *man,
>struct ttm_resource *res)
>  {
> -   spin_lock(&man->bdev->lru_lock);
> -   man->usage -= res->bo->base.size;
> -   spin_unlock(&man->bdev->lru_lock);
> +   struct ttm_device *bdev = man->bdev;
> +
> +   spin_lock(&bdev->lru_lock);
> +   list_del_init(&res->lru);
> +   if (res->bo && bdev->funcs->del_from_lru_notify)
> +   bdev->funcs->del_from_lru_notify(res->bo);
> +   man->usage -= res->num_pages << PAGE_SHIFT;

Above we are using the bo->base.size for tracking usage, but here we
are using num_pages. Is it guaranteed that bo->base.size is always
page aligned? Do we need some kind of WARN_ON()? Perhaps also sanity
checking that usage == 0 when tearing down the man?

Re: [PATCH 1/5] drm/fb-helper: Fix clip rectangle height

[Javier Martinez Canillas]

Hello Thomas,

On 2/6/22 20:29, Thomas Zimmermann wrote:
> Computing the clip rectangle is prone to off-by-one errors when writes
> happen near the end of a memory page. Point the end of the memory area
> to the first trailing byte, so that (end - start) returns the area's
> length.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 2/5] drm/fb-helper: Fix vertical damage clipping

[Javier Martinez Canillas]

On 2/6/22 20:29, Thomas Zimmermann wrote:
> Don't clip the damage rectangle against the viewport. This only
> works if the viewport is located at the beginning of the video
> memory and the video memory doesn't extend the screen (i.e., if
> there's no overallocation).
> 
> Fbdev emulation transfers data from write operations into a
> possible shadow buffer, then into a GEM buffer object, and finally
> via graphics driver onto the screen.
> 
> If callers write outside the currently visible area, clipping the
> damage rectangle against the viewport will loose these updates in
> the shadow buffer and the fbdev's buffer object will contain stale
> data. Panning the viewport to the stale area of the buffer will
> display obsolete data.
> 
> Instead, mark all written areas as damaged, so that the damage
> handler updates the buffer object from the shadow buffer for all
> such areas. The graphics driver's later has the option of clipping
> the damaged area against the viewport when updating the screen
> from the buffer object.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Add fallback inside memcpy_from_wc functions

[Balasubramani Vivekanandan]

On 08.02.2022 11:11, Lucas De Marchi wrote:
> On Mon, Feb 07, 2022 at 09:43:08PM +0530, Balasubramani Vivekanandan wrote:
> > memcpy_from_wc functions can fail if SSE4.1 is not supported or the
> > supplied addresses are not 16-byte aligned. It was then upto to the
> > caller to use memcpy as fallback.
> > Now fallback to memcpy is implemented inside memcpy_from_wc functions
> > relieving the user from checking the return value of i915_memcpy_from_wc
> > and doing fallback.
> > 
> > When doing copying from io memory address memcpy_fromio should be used
> > as fallback. So a new function is added to the family of memcpy_to_wc
> > functions which should be used while copying from io memory.
> > 
> > This change is implemented also with an intention to perpare for porting
> > memcpy_from_wc code to ARM64. Since SSE4.1 is not valid for ARM,
> > accelerated reads will not be supported and the driver should rely on
> > fallback always.
> > So there would be few more places in the code where fallback should be
> > introduced. For e.g. GuC log relay is currently not using fallback since
> > a GPU supporting GuC submission will mostly have SSE4.1 enabled CPU.
> > This is no more valid with Discrete GPU and with enabling support for
> > ARM64.
> > With fallback moved inside memcpy_from_wc function, call sites would
> > look neat and fallback can be implemented in a uniform way.
> > 
> > Signed-off-by: Balasubramani Vivekanandan 
> > 
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.c |  5 +-
> > drivers/gpu/drm/i915/gt/selftest_reset.c   |  8 ++-
> > drivers/gpu/drm/i915/i915_gpu_error.c  |  9 ++-
> > drivers/gpu/drm/i915/i915_memcpy.c | 78 --
> > drivers/gpu/drm/i915/i915_memcpy.h | 18 ++---
> > 5 files changed, 78 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index e03e362d320b..e187c4bfb7e4 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -444,7 +444,7 @@ static void
> > i915_gem_object_read_from_page_iomap(struct drm_i915_gem_object *obj, u64 
> > offset, void *dst, int size)
> > {
> > void __iomem *src_map;
> > -   void __iomem *src_ptr;
> > +   const void __iomem *src_ptr;
> > dma_addr_t dma = i915_gem_object_get_dma_address(obj, offset >> 
> > PAGE_SHIFT);
> > 
> > src_map = io_mapping_map_wc(&obj->mm.region->iomap,
> > @@ -452,8 +452,7 @@ i915_gem_object_read_from_page_iomap(struct 
> > drm_i915_gem_object *obj, u64 offset
> > PAGE_SIZE);
> > 
> > src_ptr = src_map + offset_in_page(offset);
> > -   if (!i915_memcpy_from_wc(dst, (void __force *)src_ptr, size))
> > -   memcpy_fromio(dst, src_ptr, size);
> > +   i915_io_memcpy_from_wc(dst, src_ptr, size);
> 
> nitpick, but maybe to align with the memcpy_fromio() API this would
> better be named i915_memcpy_fromio_wc()?

I too thought for a moment should I rename to i915_memcpy_fromio_wc()
but stayed with the current name, when preparing the patch.
I will rename it.

> 
> > 
> > io_mapping_unmap(src_map);
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c 
> > b/drivers/gpu/drm/i915/gt/selftest_reset.c
> > index 37c38bdd5f47..64b8521a8b28 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_reset.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
> > @@ -99,8 +99,10 @@ __igt_reset_stolen(struct intel_gt *gt,
> > memset_io(s, STACK_MAGIC, PAGE_SIZE);
> > 
> > in = (void __force *)s;
> > -   if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
> > +   if (i915_can_memcpy_from_wc(tmp, in, PAGE_SIZE)) {
> > +   i915_io_memcpy_from_wc(tmp, in, PAGE_SIZE);
> > in = tmp;
> > +   }
> > crc[page] = crc32_le(0, in, PAGE_SIZE);
> > 
> > io_mapping_unmap(s);
> > @@ -135,8 +137,10 @@ __igt_reset_stolen(struct intel_gt *gt,
> >   PAGE_SIZE);
> > 
> > in = (void __force *)s;
> > -   if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
> > +   if (i915_can_memcpy_from_wc(tmp, in, PAGE_SIZE)) {
> > +   i915_io_memcpy_from_wc(tmp, in, PAGE_SIZE);
> 
> but you removed __iomem above
Yeah, it is a mistake. I will change it. There is one more place in the
same file which needs correction.

Regards,
Bala
> 
> > in = tmp;
> > +   }
> > x = crc32_le(0, in, PAGE_SIZE);
> > 
> > if (x != crc[page] &&
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index 127ff56c8ce6..2c14a28c 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -297,8 +297,10 @@ static int compress_page(struct i915_vma_compress *c,
> > struct z_stream_s *zstream = &c->zstream;
> > 
> > zstr

Re: [PATCH 3/5] drm/fb-helper: Calculate damaged area in separate helper

[Javier Martinez Canillas]

On 2/6/22 20:29, Thomas Zimmermann wrote:
> Add drm_fb_helper_clip_to_memory_range(), a helper function that
> accepts an linear range of video memory and converts it into a
> rectangle. The computed rectangle describes the damaged area in
> terms of scanlines and pixels per scanline.
> 
> While at it, make the code more readable by using struct drm_rect
> and related helpers.
> 
> The code was previously part of the deferred I/O helpers, but is
> also useful for damage handling of regular write operations. Update
> the deferred I/O code to use the new function.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 26 --
>  1 file changed, 20 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 87c47093c3a2..ae98990c7b66 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -680,6 +680,19 @@ static void drm_fb_helper_damage(struct fb_info *info, 
> u32 x, u32 y,
>   schedule_work(&helper->damage_work);
>  }
>  
> +/* Convert memory region into area of scanlines and pixels per scanline */
> +static void drm_fb_helper_clip_to_memory_range(struct fb_info *info, off_t 
> off, size_t len,
> +struct drm_rect *clip)
> +{

Shouldn't be called drm_fb_helper_clip_from_memory_range() or
drm_fb_helper_memory_range_to_clip() instead ?

Otherwise it looks good to me.

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 4/5] drm/fb-helper: Clip damage area to written memory range

[Javier Martinez Canillas]

On 2/6/22 20:29, Thomas Zimmermann wrote:
> Write helpers used to mark the complete screen as dirty. This is
> wasteful for writes that only change a small portion of the screen.
> Fix the problem by computing the damaged area from the written
> memory range and perform damage handling accordingly.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

>  drivers/gpu/drm/drm_fb_helper.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ae98990c7b66..bed58be1b205 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -754,11 +754,18 @@ EXPORT_SYMBOL(drm_fb_helper_sys_read);
>  ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char __user *buf,
>   size_t count, loff_t *ppos)
>  {
> + loff_t pos = *ppos;
>   ssize_t ret;
> + struct drm_rect damage_area;
>  
>   ret = fb_sys_write(info, buf, count, ppos);
> - if (ret > 0)
> - drm_fb_helper_damage(info, 0, 0, info->var.xres, 
> info->var.yres);
> + if (ret <= 0)
> + return ret;
> +

I also like how you cleaned up the error checking here and below
to just return early, instead of checking if ret > 0 to perform
the damage handling.

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 01/23] drm/encoder: Add of_graph port to struct drm_encoder

[Jani Nikula]

On Wed, 09 Feb 2022, Sascha Hauer  wrote:
> David, Daniel,
>
> I'll need a word from you regarding this patch. It's needed in patch
> 22/23 in this series.
> vop2_crtc_atomic_enable() needs to control the mux which routes the
> display output to the different encoders. Which encoder is used is
> described in the of_graph port, so I need a way to identify the encoder
> in the device tree.

I think the question is how useful is this going to be in general. IMO
we should not be adding members that are useful in a single driver only.

For example i915 wraps encoders with:

struct intel_encoder {
struct drm_encoder base;

/* i915 specific stuff here*/
};

So that we can add stuff of our own there. Of course, it does mean a
bunch of overhead for the first time you need to do it. But adding
driver specific stuff to struct drm_encoder adds overhead for everyone.

All that said, *I* don't know how useful the port member would be in
drivers that use device tree. Maybe it's worth it.

BR,
Jani.

>
> Sascha
>
> On Wed, Feb 09, 2022 at 10:53:28AM +0100, Sascha Hauer wrote:
>> Add a device node to drm_encoder which corresponds with the port node
>> in the DT description of the encoder. This allows drivers to find the
>> of_graph link between a crtc and an encoder.
>> 
>> Signed-off-by: Sascha Hauer 
>> ---
>>  include/drm/drm_encoder.h | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h
>> index 6e91a0280f31..3acd054b1eb3 100644
>> --- a/include/drm/drm_encoder.h
>> +++ b/include/drm/drm_encoder.h
>> @@ -99,6 +99,8 @@ struct drm_encoder {
>>  struct drm_device *dev;
>>  struct list_head head;
>>  
>> +struct device_node *port;
>> +
>>  struct drm_mode_object base;
>>  char *name;
>>  /**
>> -- 
>> 2.30.2
>> 
>> 

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 5/5] drm/fb-helper: Clip damage area horizontally

[Javier Martinez Canillas]

On 2/6/22 20:29, Thomas Zimmermann wrote:
> Clip the damage area horizontally if only a single scanline has been
> changed. This is helpful to reduce the memcpy overhead for small writes.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Linux Engineering
Red Hat

[PATCH] drm/i915/ttm: tweak priority hint selection

[Matthew Auld]

For some reason we are selecting PRIO_HAS_PAGES when we don't have
mm.pages, and vice versa.

v2(Thomas):
  - Add missing fixes tag

Fixes: 213d50927763 ("drm/i915/ttm: Introduce a TTM i915 gem object backend")
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 84cae740b4a5..1eb2fd81c5b6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -840,11 +840,9 @@ void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj)
} else if (obj->mm.madv != I915_MADV_WILLNEED) {
bo->priority = I915_TTM_PRIO_PURGE;
} else if (!i915_gem_object_has_pages(obj)) {
-   if (bo->priority < I915_TTM_PRIO_HAS_PAGES)
-   bo->priority = I915_TTM_PRIO_HAS_PAGES;
+   bo->priority = I915_TTM_PRIO_NO_PAGES;
} else {
-   if (bo->priority > I915_TTM_PRIO_NO_PAGES)
-   bo->priority = I915_TTM_PRIO_NO_PAGES;
+   bo->priority = I915_TTM_PRIO_HAS_PAGES;
}
 
ttm_bo_move_to_lru_tail(bo, bo->resource, NULL);
-- 
2.34.1

Re: [PATCH v13 0/9] MIPS: JZ4780 and CI20 HDMI

[Paul Cercueil]

Hi Nikolaus,

I tried applying patches 1-2, but they don't apply cleanly on top of 
drm-misc/drm-misc-next.


Could you rebase on top of that tree?

Cheers,
-Paul


Le mer., févr. 2 2022 at 17:31:14 +0100, H. Nikolaus Schaller 
 a écrit :

PATCH V13 2022-02-02 17:31:22:
* 7/9: remove call to gpiod_set_value() because of GPIOD_OUT_HIGH (by 
p...@crapouillou.net)

* 4/9: replace ".." by "." (by p...@crapouillou.net)
* 3/9: remove old hdmi-5v-power in the example (by 
p...@crapouillou.net)
* 2/9: disable handling of plane f0 only for jz4780 (by 
p...@crapouillou.net)


PATCH V12 2022-01-31 13:26:54:
This version reworks how hdmi ddc power is controlled by connector 
and not

by ddc/hdmi bridge driver.

Also some patches of the previous version of this series have been 
removed

since they are already applied to mips-next/linux/next/v5.17-rc1.

Fixes and changes:

- repair interworking of dw-hdmi with connector-hdmi (by 
h...@goldelico.com)
- fix JZ_REG_LCD_OSDC setup for jz4780 (by h...@goldelico.com and 
p...@crapouillou.net)
- adjustments for ci20.dts to use connector gpio for +5v (suggested 
by several)
- to add control of "ddc-en-gpios" to hdmi-connector driver (by 
h...@goldelico.com)
- regulator code removed because we now use the "ddc-en-gpios" of the 
connector

  driver (suggested by p...@crapouillou.net)
- bindings: addition of "ddc-i2c-bus" and "hdmi-5v-supply" removed 
(suggested by robh...@kernel.org)

- rebase on v5.17-rc2

PATCH V11 2021-12-02 19:39:52:
- patch 4/8: change devm_regulator_get_optional to devm_regulator_get 
and

 remove NULL check (requested by broo...@kernel.org)
- patch 3/8: make hdmi-5v-supply required (requested by 
broo...@kernel.org)


PATCH V10 2021-11-30 22:26:41:
- patch 3/8: fix $id and $ref paths (found by r...@kernel.org)

PATCH V9 2021-11-24 22:29:14:
- patch 6/8: remove optional <0> for assigned-clocks and 
unintentionally included "unwedge" setup (found by 
p...@crapouillou.net)

- patch 4/8: some cosmetics
 make regulator enable/disable only if not NULL (found by 
p...@crapouillou.net)
 simplify/fix error handling and driver cleanup on remove 
(proposed by p...@crapouillou.net)
- patch 3/8: fix #include path in example (found by 
p...@crapouillou.net)
 fix missing "i" in unevaluatedProperties (found by 
r...@kernel.org)
 fix 4 spaces indentation for required: property (found 
by r...@kernel.org)


PATCH V8 2021-11-23 19:14:00:
- fix a bad editing result from patch 2/8 (found by 
p...@crapouillou.net)


PATCH V7 2021-11-23 18:46:23:
- changed gpio polarity of hdmi_power to 0 (suggested by 
p...@crapouillou.net)

- fixed LCD1 irq number (bug found by p...@crapouillou.net)
- removed "- 4" for calculating max_register (suggested by 
p...@crapouillou.net)
- use unevaluatedPropertes instead of additionalProperties (suggested 
by r...@kernel.org)
- moved and renamed ingenic,jz4780-hdmi.yaml (suggested by 
r...@kernel.org)
- adjusted assigned-clocks changes to upstream which added some for 
SSI (by h...@goldelico.com)
- rebased and tested with v5.16-rc2 + patch set drm/ingenic by 
p...@crapouillou.net (by h...@goldelico.com)


PATCH V6 2021-11-10 20:43:33:
- changed CONFIG_DRM_INGENIC_DW_HDMI to "m" (by h...@goldelico.com)
- made ingenic-dw-hdmi an independent platform driver which can be 
compiled as module
  and removed error patch fixes for IPU (suggested by 
p...@crapouillou.net)
- moved assigned-clocks from jz4780.dtsi to ci20.dts (suggested by 
p...@crapouillou.net)
- fixed reg property in jz4780.dtsi to cover all registers incl. 
gamma and vee (by h...@goldelico.com)
- added a base patch to calculate regmap size from DTS reg property 
(requested by p...@crapouillou.net)
- restored resetting all bits except one in LCDOSDC (requested by 
p...@crapouillou.net)

- clarified setting of cpos (suggested by p...@crapouillou.net)
- moved bindings definition for ddc-i2c-bus (suggested by 
p...@crapouillou.net)
- simplified mask definitions for JZ_LCD_DESSIZE (requested by 
p...@crapouillou.net)
- removed setting alpha premultiplication (suggested by 
p...@crapouillou.net)

- removed some comments (suggested by p...@crapouillou.net)

PATCH V5 2021-10-05 14:28:44:
- dropped mode_fixup and timings support in dw-hdmi as it is no 
longer needed in this V5 (by h...@goldelico.com)
- dropped "drm/ingenic: add some jz4780 specific features" 
(stimulated by p...@crapouillou.net)
- fixed typo in commit subject: "synopsis" -> "synopsys" (by 
h...@goldelico.com)
- swapped clocks in jz4780.dtsi to match synopsys,dw-hdmi.yaml (by 
h...@goldelico.com)
- improved, simplified, fixed, dtbschecked ingenic-jz4780-hdmi.yaml 
and made dependent of bridge/synopsys,dw-hdmi.yaml (based on 
suggestions by max...@cerno.tech)
- fixed binding vs. driver&DTS use of hdmi-5v regulator (suggested by 
max...@cerno.tech)
- dropped "drm/bridge: synopsis: Fix to properly handle HPD" - was a 
no longer needed workaround for a previous version

  (sugge

Re: [PATCH v13 5/9] drm/synopsys+ingenic: repair hot plug detection

[Paul Cercueil]

Hi Nikolaus,

Le mer., févr. 2 2022 at 17:31:19 +0100, H. Nikolaus Schaller 
 a écrit :

so that it calls drm_kms_helper_hotplug_event().

We need to set .poll_enabled but that struct component
can only be accessed in the core code. Hence we add a public
setter function.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 9 +
 drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c | 2 ++
 include/drm/bridge/dw_hdmi.h  | 1 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c

index 54d8fdad395f5..52e7cd2e020d3 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3216,6 +3216,15 @@ static int dw_hdmi_parse_dt(struct dw_hdmi 
*hdmi)

return 0;
 }

+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable)
+{
+   if (hdmi->bridge.dev)
+   hdmi->bridge.dev->mode_config.poll_enabled = enable;
+   else
+   dev_warn(hdmi->dev, "no hdmi->bridge.dev");
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_enable_poll);
+
 struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
  const struct dw_hdmi_plat_data *plat_data)
 {
diff --git a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c 
b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c

index 34e986dd606cf..90547a28dc5c7 100644
--- a/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
+++ b/drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c
@@ -55,6 +55,8 @@ ingenic_dw_hdmi_mode_valid(struct dw_hdmi *hdmi, 
void *data,

if (mode->clock > 216000)
return MODE_CLOCK_HIGH;

+   dw_hdmi_enable_poll(hdmi, true);
+


It would be a better idea to move this patch before the patch that 
creates ingenic-dw-hdmi.c. Then you wouldn't have to patch a file that 
was just introduced.


As for the patch itself, I guess it's fine, but is that really needed? 
My understanding is that it's the hdmi-connector's job to poll.


Cheers,
-Paul


return MODE_OK;
 }

diff --git a/include/drm/bridge/dw_hdmi.h 
b/include/drm/bridge/dw_hdmi.h

index 2a1f85f9a8a3f..963960794b40e 100644
--- a/include/drm/bridge/dw_hdmi.h
+++ b/include/drm/bridge/dw_hdmi.h
@@ -196,5 +196,6 @@ enum drm_connector_status 
dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,

 void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
bool force, bool disabled, bool rxsense);
 void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data);
+void dw_hdmi_enable_poll(struct dw_hdmi *hdmi, bool enable);

 #endif /* __IMX_HDMI_H__ */
--
2.33.0

Re: [PATCH 2/9] drm/ttm: move the LRU into resource handling v3

[Christian König]

Am 09.02.22 um 11:09 schrieb Matthew Auld:

On Wed, 9 Feb 2022 at 08:41, Christian König
 wrote:

This way we finally fix the problem that new resource are
not immediately evict-able after allocation.

That has caused numerous problems including OOM on GDS handling
and not being able to use TTM as general resource manager.

v2: stop assuming in ttm_resource_fini that res->bo is still valid.
v3: cleanup kerneldoc, add more lockdep annotation

Signed-off-by: Christian König 
Tested-by: Bas Nieuwenhuizen 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |   8 +-
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c |   2 +-
  drivers/gpu/drm/ttm/ttm_bo.c| 115 ++
  drivers/gpu/drm/ttm/ttm_bo_util.c   |   1 -
  drivers/gpu/drm/ttm/ttm_device.c|  64 ++---
  drivers/gpu/drm/ttm/ttm_resource.c  | 122 +++-
  include/drm/ttm/ttm_bo_api.h|  16 
  include/drm/ttm/ttm_bo_driver.h |  29 +-
  include/drm/ttm/ttm_resource.h  |  35 +++
  9 files changed, 197 insertions(+), 195 deletions(-)




  /**
   * ttm_resource_init - resource object constructure
   * @bo: buffer object this resources is allocated for
@@ -52,10 +156,12 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
 res->bus.is_iomem = false;
 res->bus.caching = ttm_cached;
 res->bo = bo;
+   INIT_LIST_HEAD(&res->lru);

 man = ttm_manager_type(bo->bdev, place->mem_type);
 spin_lock(&bo->bdev->lru_lock);
 man->usage += bo->base.size;
+   ttm_resource_move_to_lru_tail(res, NULL);
 spin_unlock(&bo->bdev->lru_lock);
  }
  EXPORT_SYMBOL(ttm_resource_init);
@@ -66,15 +172,21 @@ EXPORT_SYMBOL(ttm_resource_init);
   * @res: the resource to clean up
   *
   * Should be used by resource manager backends to clean up the TTM resource
- * objects before freeing the underlying structure. Counterpart of
- * &ttm_resource_init
+ * objects before freeing the underlying structure. Makes sure the resource is
+ * removed from the LRU before destruction.
+ * Counterpart of &ttm_resource_init.
   */
  void ttm_resource_fini(struct ttm_resource_manager *man,
struct ttm_resource *res)
  {
-   spin_lock(&man->bdev->lru_lock);
-   man->usage -= res->bo->base.size;
-   spin_unlock(&man->bdev->lru_lock);
+   struct ttm_device *bdev = man->bdev;
+
+   spin_lock(&bdev->lru_lock);
+   list_del_init(&res->lru);
+   if (res->bo && bdev->funcs->del_from_lru_notify)
+   bdev->funcs->del_from_lru_notify(res->bo);
+   man->usage -= res->num_pages << PAGE_SHIFT;

Above we are using the bo->base.size for tracking usage, but here we
are using num_pages. Is it guaranteed that bo->base.size is always
page aligned? Do we need some kind of WARN_ON()? Perhaps also sanity
checking that usage == 0 when tearing down the man?


Good point, going to add that and consistently using res->num_pages for 
both.


Thanks,
Christian.

Re: [PATCH 6/9] drm/amdgpu: remove VRAM accounting

[Christian König]

Am 09.02.22 um 10:53 schrieb Matthew Auld:

On Wed, 9 Feb 2022 at 08:41, Christian König
 wrote:

This is provided by TTM now.

Also switch man->size to bytes instead of pages and fix the double
printing of size and usage in debugfs.

Signed-off-by: Christian König 
Tested-by: Bas Nieuwenhuizen 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c  |  6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  |  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h  |  2 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c |  6 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 58 +++-
  6 files changed, 31 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index e8440d306496..025748e9c772 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -314,7 +314,7 @@ static void amdgpu_cs_get_threshold_for_moves(struct 
amdgpu_device *adev,
 }

 total_vram = adev->gmc.real_vram_size - 
atomic64_read(&adev->vram_pin_size);
-   used_vram = amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
+   used_vram = ttm_resource_manager_usage(&adev->mman.vram_mgr.manager);
 free_vram = used_vram >= total_vram ? 0 : total_vram - used_vram;

 spin_lock(&adev->mm_stats.lock);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 9ff4aced5da7..0beab961b18b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -678,7 +678,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
 ui64 = atomic64_read(&adev->num_vram_cpu_page_faults);
 return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
 case AMDGPU_INFO_VRAM_USAGE:
-   ui64 = amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
+   ui64 = ttm_resource_manager_usage(&adev->mman.vram_mgr.manager);
 return copy_to_user(out, &ui64, min(size, 8u)) ? -EFAULT : 0;
 case AMDGPU_INFO_VIS_VRAM_USAGE:
 ui64 = amdgpu_vram_mgr_vis_usage(&adev->mman.vram_mgr);
@@ -717,6 +717,8 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
 struct drm_amdgpu_memory_info mem;
 struct ttm_resource_manager *gtt_man =
 &adev->mman.gtt_mgr.manager;
+   struct ttm_resource_manager *vram_man =
+   &adev->mman.vram_mgr.manager;

 memset(&mem, 0, sizeof(mem));
 mem.vram.total_heap_size = adev->gmc.real_vram_size;
@@ -724,7 +726,7 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
 atomic64_read(&adev->vram_pin_size) -
 AMDGPU_VM_RESERVED_VRAM;
 mem.vram.heap_usage =
-   amdgpu_vram_mgr_usage(&adev->mman.vram_mgr);
+   ttm_resource_manager_usage(vram_man);
 mem.vram.max_allocation = mem.vram.usable_heap_size * 3 / 4;

 mem.cpu_accessible_vram.total_heap_size =
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d178fbec7048..5859ed0552a4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1884,7 +1884,7 @@ void amdgpu_ttm_set_buffer_funcs_status(struct 
amdgpu_device *adev, bool enable)
 size = adev->gmc.real_vram_size;
 else
 size = adev->gmc.visible_vram_size;
-   man->size = size >> PAGE_SHIFT;
+   man->size = size;
 adev->mman.buffer_funcs_enabled = enable;
  }

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 120b69ec9885..cbee84a77331 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -44,7 +44,6 @@ struct amdgpu_vram_mgr {
 spinlock_t lock;
 struct list_head reservations_pending;
 struct list_head reserved_pages;
-   atomic64_t usage;
 atomic64_t vis_usage;
  };

@@ -127,7 +126,6 @@ int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
  void amdgpu_vram_mgr_free_sgt(struct device *dev,
   enum dma_data_direction dir,
   struct sg_table *sgt);
-uint64_t amdgpu_vram_mgr_usage(struct amdgpu_vram_mgr *mgr);
  uint64_t amdgpu_vram_mgr_vis_usage(struct amdgpu_vram_mgr *mgr);
  int amdgpu_vram_mgr_reserve_range(struct amdgpu_vram_mgr *mgr,
   uint64_t start, uint64_t size);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
index 07bc0f504713..3a25dd220786 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
+++ b/drivers/gpu/drm/amd/

Re: [PATCH v13 6/9] dw-hdmi/ingenic-dw-hdmi: repair interworking with hdmi-connector

[Paul Cercueil]

Hi Nikolaus,

Le mer., févr. 2 2022 at 17:31:20 +0100, H. Nikolaus Schaller 
 a écrit :
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus 
fmts callbacks")


introduced a new mechanism to negotiate bus formats between hdmi 
connector

and the synopsys hdmi driver inside the jz4780.

By this, the dw-hdmi is no longer the only bridge and sets up a list
of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts().

This includes MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the jz4780 
but only

produces a black screen.

This fix is based on the observation that max_bpc = 0 when running 
this
function while info->bpc = 8. Since the formats checks before this 
always test
for max_bpc >= info->pbc indirectly my assumption is that we must 
check it

here as well.


This fix looks really strange to me, so I'll let the DRM experts 
comment.


It would still be better to move the patch before the introduction of 
dw-ingenic-hdmi.c, so that once this one is introduced, everything 
works. This also enables bisectability.


Cheers,
-Paul




Adding the proposed patch makes the CI20/jz4780 panel work again in
MEDIA_BUS_FMT_RGB888_1X24 mode.

Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus 
fmts callbacks")

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c

index 52e7cd2e020d3..34703a15ee4ff 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2620,10 +2620,10 @@ static u32 
*dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge,

output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
}

-   if (info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+	if (max_bpc >= info->bpc && info->color_formats & 
DRM_COLOR_FORMAT_YCRCB422)

output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;

-   if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+	if (max_bpc >= info->bpc && info->color_formats & 
DRM_COLOR_FORMAT_YCRCB444)

output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;

/* Default 8bit RGB fallback */
--
2.33.0

Re: [PATCH v3 0/7] drm: Add driver for Solomon SSD130X OLED displays

[Geert Uytterhoeven]

Hi Javier,

On Wed, Feb 9, 2022 at 10:03 AM Javier Martinez Canillas
 wrote:
> This patch series adds a DRM driver for the Solomon OLED SSD1305, SSD1306,
> SSD1307 and SSD1309 displays. It is a port of the ssd1307fb fbdev driver.

[...]

> - Fix a bug when doing partial updates (Geert Uytterhoeven)

Thanks, the text console is now more or less working as expected.
There is still an issue with the cursor, though.
After doing "echo hello > /dev/tty0", the text appears, but the cursor
is gone. "clear > /dev/tty0" brings it back.

The execution time of "time ls" has improved. It now takes 1.21s
(0.86s with ssd1306fb).

The logo is not shown, even when I create a 16-color or 224-color
version of the small monochrome logo I'm using.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v3 4/7] drm/solomon: Add SSD130X OLED displays I2C support

[Geert Uytterhoeven]

Hi Javier,

On Wed, Feb 9, 2022 at 10:03 AM Javier Martinez Canillas
 wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over I2C.
>
> Signed-off-by: Javier Martinez Canillas 

Thanks for your patch!

> --- /dev/null
> +++ b/drivers/gpu/drm/solomon/ssd130x-i2c.c

> +static const struct of_device_id ssd130x_of_match[] = {
> +   {
> +   .compatible = "solomon,ssd1305fb-i2c",
> +   .data = (void *)&ssd130x_ssd1305_deviceinfo,

The casts are not needed.

> +   },
> +   {
> +   .compatible = "solomon,ssd1306fb-i2c",
> +   .data = (void *)&ssd130x_ssd1306_deviceinfo,
> +   },
> +   {
> +   .compatible = "solomon,ssd1307fb-i2c",
> +   .data = (void *)&ssd130x_ssd1307_deviceinfo,
> +   },
> +   {
> +   .compatible = "solomon,ssd1309fb-i2c",
> +   .data = (void *)&ssd130x_ssd1309_deviceinfo,
> +   },
> +   { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, ssd130x_of_match);

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v3 5/7] (WIP) drm/solomon: Add SSD130X OLED displays SPI support

[Geert Uytterhoeven]

Hi Javier,

On Wed, Feb 9, 2022 at 10:12 AM Javier Martinez Canillas
 wrote:
> The ssd130x driver only provides the core support for these devices but it
> does not have any bus transport logic. Add a driver to interface over SPI.
>
> Signed-off-by: Javier Martinez Canillas 

Thanks for your patch!

> --- /dev/null
> +++ b/drivers/gpu/drm/solomon/ssd130x-spi.c

> +static const struct of_device_id ssd130x_of_match[] = {
> +   {
> +   .compatible = "solomon,ssd1305fb-spi",

This needs an update to the DT bindings.
Hence this may be a good time to deprecate the existing
"solomon,ssd130*fb-i2c" compatible values, and switch to
"solomon,ssd130*fb" instead, for both I2C and SPI.
Of course the I2C subdriver still has to bind against the old values,
too, for backwards compatibility.

> +   .data = (void *)&ssd130x_ssd1305_deviceinfo,

The casts are not needed.

> +   },
> +   {
> +   .compatible = "solomon,ssd1306fb-spi",
> +   .data = (void *)&ssd130x_ssd1306_deviceinfo,
> +   },
> +   {
> +   .compatible = "solomon,ssd1307fb-spi",
> +   .data = (void *)&ssd130x_ssd1307_deviceinfo,
> +   },
> +   {
> +   .compatible = "solomon,ssd1309fb-spi",
> +   .data = (void *)&ssd130x_ssd1309_deviceinfo,
> +   },
> +   { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(of, ssd130x_of_match);
> +

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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 v2 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

[Noralf Trønnes]

Den 09.02.2022 10.04, skrev Maxime Ripard:
> Hi Noralf,
> 
> On Tue, Feb 08, 2022 at 01:16:44PM +0100, Noralf Trønnes wrote:
>> Den 08.02.2022 00.20, skrev Rob Herring:
>>> On Thu, Jan 27, 2022 at 10:37:22AM +0100, Maxime Ripard wrote:
 Hi,

 On Tue, Jan 25, 2022 at 06:56:58PM +0100, Noralf Trønnes wrote:
> Add binding for MIPI DBI compatible SPI panels.
>
> v2:
> - Fix path for panel-common.yaml
> - Use unevaluatedProperties
> - Drop properties which are in the allOf section
> - Drop model property (Rob)
>
> Signed-off-by: Noralf Trønnes 
> ---
>  .../display/panel/panel-mipi-dbi-spi.yaml | 59 +++
>  1 file changed, 59 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> new file mode 100644
> index ..b7cbeea0f8aa
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> @@ -0,0 +1,59 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MIPI DBI SPI Panels Device Tree Bindings
> +
> +maintainers:
> +  - Noralf Trønnes 
> +
> +description:
> +  This binding is for display panels using a MIPI DBI controller
> +  in SPI mode.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> +  compatible:
> +const: panel-mipi-dbi-spi

 You need contains here, otherwise it will error out if you have two 
 compatibles.
>>>
>>> Shouldn't it always have 2?
>>>
>>> Either way, this has to be split up between a common, shareable schema 
>>> and specific, complete schema(s). Like this:
>>>
>>> - A schema for everything common (that allows additional properties)
>>>
>>> - A schema for 'panel-mipi-dbi-spi' referencing the common schema plus 
>>>   'unevaluatedProperties: false'
>>>
>>> - Schemas for panels with their own additional properties (regulators, 
>>>   GPIOs, etc.)
>>>
>>> LVDS was restructured like this IIRC.
>>
>> The whole point of this exercise is to avoid the need for controller
>> specific bindings.
> 
> I'm not sure to follow you here, nothing that either Rob or I discussed
> would require a controller specific binding.
> 
> It would require a controller compatible, but the binding itself can
> just mandate a controller compatible in addition to the
> panel-mipi-dbi-spi compatible, without enforcing anything wrt the
> compatible itself.
> 
> And the driver will just match panel-mipi-dbi-spi so there won't be any
> driver change either?
> 
> In essence, it would be similar to the bindings of panel-lvds or the
> AT24 EEPROM binding: you have two compatibles, but the driver is generic
> and will just infer its behaviour based on the DT properties (and in our
> case will load a firmware based on the specific compatible).
> 
> Wouldn't that work?
> 

Oh, I misunderstood then.
I looked at the panel-lvds binding and since it didn't have any example
it looked like a schema that controllers/panels would include and not
something that would be used on its own.

>> This binding will cover all specifics about these
>> controllers except for one thing and that is the controller
>> configuration. Each controller has its own configuration commands. These
>> commands will be loaded as a firmware file based on the compatible and
>> applied by the driver.
>>
>> So this binding, the panel-common and spi-peripheral-props covers
>> everything except for the controller configuration.
>>
>> Here's a copy of the DBI spec: https://www.docin.com/p-219732497.html
>>
>> This is my current version of the binding:
>>
>> # SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> %YAML 1.2
>> ---
>> $id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>
>> title: MIPI DBI SPI Panel
>>
>> maintainers:
>>   - Noralf Trønnes 
>>
>> description: |
>>   This binding is for display panels using a MIPI DBI compatible controller
>>   in SPI mode.
>>
>>   The MIPI Alliance Standard for Display Bus Interface defines the
>> electrical
>>   and logical interfaces for display controllers historically used in mobile
>>   phones. The standard defines 4 display architecture types and this
>> binding is
>>   for type 1 which has full frame memory. There are 3 interface types in the
>>   standard and type C is the serial interface.
>>
>>   The standard defines the following interface signals for type C:
>>   - Power:
>> - Vdd: Power supply for 

Re: [PATCH 7/8] mm: remove the extra ZONE_DEVICE struct page refcount

[Jason Gunthorpe]

On Wed, Feb 09, 2022 at 07:23:45AM +0100, Christoph Hellwig wrote:
> On Tue, Feb 08, 2022 at 07:30:11PM -0800, Dan Williams wrote:
> > Interesting. I had expected that to really fix the refcount problem
> > that fs/dax.c would need to start taking real page references as pages
> > were added to a mapping, just like page cache.
> 
> I think we should do that eventually.  But I think this series that
> just attacks the device private type and extends to the device coherent
> and p2p enhacements is a good first step to stop the proliferation of
> the one off refcount and to allow to deal with the fsdax pages in another
> more focuessed series.

It is nice, but the other series are still impacted by the fsdax mess
- they still stuff pages into ptes without proper refcounts and have
to carry nonsense to dance around this problem.

I certainly would be unhappy if the amd driver, for instance, gained
the fsdax problem as well and started pushing 4k pages into PMDs.

Jason