Re: [PATCH] drm/Makefile: Move tiny drivers before native drivers

[Thomas Zimmermann]

Hi,

thanks for the patch.

Am 08.11.23 um 03:46 schrieb Huacai Chen:

After commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
device_initcall to subsys_initcall_sync") some Lenovo laptops get a blank
screen until the display manager starts.

This regression occurs with such a Kconfig combination:
CONFIG_SYSFB=y
CONFIG_SYSFB_SIMPLEFB=y
CONFIG_DRM_SIMPLEDRM=y
CONFIG_DRM_I915=y  # Or other native drivers such as radeon, amdgpu

If replace CONFIG_DRM_SIMPLEDRM with CONFIG_FB_SIMPLE (they use the same
device), there is no blank screen. The root cause is the initialization
order, and this order depends on the Makefile.

FB_SIMPLE is before native DRM drivers (e.g. i915, radeon, amdgpu, and
so on), but DRM_SIMPLEDRM is after them. Thus, if we use FB_SIMPLE, I915
will takeover FB_SIMPLE, then no problem; and if we use DRM_SIMPLEDRM,
DRM_SIMPLEDRM will try to takeover I915, but fails to work.


But what exactly is the problem? From the lengthy discussion threat, it 
looks like you've stumbled across a long-known problem, where the 
firmware driver probes a device that has already been taken by a native 
driver. But that should not be possible.


As you know, there's a platform device that represents the firmware 
framebuffer. The firmware drivers, such as simpledrm, bind to it. In 
i915 and the other native drivers we remove that platform device, so 
that simpledrm does not run.


We call the DRM aperture helpers at [1]. It's implemented at [2]. The 
function contains a call to sysfb_disable(), [3] which should be invoked 
for the i915 device and remove the platform device.


[1] 
https://elixir.bootlin.com/linux/v6.5/source/drivers/gpu/drm/i915/i915_driver.c#L489
[2] 
https://elixir.bootlin.com/linux/v6.5/source/drivers/video/aperture.c#L347
[3] 
https://elixir.bootlin.com/linux/v6.5/source/drivers/firmware/sysfb.c#L63


Can you investigate why this does not work? Is sysfb_disable() not being 
called? Does it remove the platform device?




So we can move the "tiny" directory before native DRM drivers to solve
this problem.


Relying on linking order is just as unreliable. The usual workaround is 
to build native drivers as modules. But first, please investigate where 
the current code fails.


Best regards
Thomas



Fixes: 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from device_initcall 
to subsys_initcall_sync")
Closes: https://lore.kernel.org/dri-devel/ZUnNi3q3yB3zZfTl@P70.localdomain/T/#t
Reported-by: Jaak Ristioja 
Signed-off-by: Huacai Chen 
---
  drivers/gpu/drm/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 8e1bde059170..db0f3d3aff43 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -141,6 +141,7 @@ obj-y   += arm/
  obj-y += display/
  obj-$(CONFIG_DRM_TTM) += ttm/
  obj-$(CONFIG_DRM_SCHED)   += scheduler/
+obj-y  += tiny/
  obj-$(CONFIG_DRM_RADEON)+= radeon/
  obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
  obj-$(CONFIG_DRM_AMDGPU)+= amd/amdxcp/
@@ -182,7 +183,6 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
  obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
  obj-y += hisilicon/
  obj-y += mxsfb/
-obj-y  += tiny/
  obj-$(CONFIG_DRM_PL111) += pl111/
  obj-$(CONFIG_DRM_TVE200) += tve200/
  obj-$(CONFIG_DRM_XEN) += xen/


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH] drm/Makefile: Move tiny drivers before native drivers

[Javier Martinez Canillas]

Hello,

On Wed, Nov 8, 2023 at 9:14 AM Thomas Zimmermann  wrote:
>
> Hi,
>

[...]

>
> Relying on linking order is just as unreliable. The usual workaround is
> to build native drivers as modules. But first, please investigate where
> the current code fails.
>

I fully agree with Thomas here. This is just papering over the issue.

I'll read the lengthy thread now to see if I can better understand
what's going on here.
-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH] drm/ttm: Schedule delayed_delete worker closer

[Christian König]

Am 07.11.23 um 20:45 schrieb Rajneesh Bhardwaj:

When a TTM BO is getting freed, to optimize the clearing operation on
the workqueue, schedule it closer to a NUMA node where the memory was
allocated. This avoids the cases where the ttm_bo_delayed_delete gets
scheduled on the CPU cores that are across interconnect boundaries such
as xGMI, PCIe etc.


This needs more background and doesn't mention that we now try to 
allocate the memory close to the device.


Something like this here should work:

Try to allocate system memory on the NUMA node the device is closest to 
and try to run delayed delete workers on a CPU of this node as well.


The background of running the delayed delete worker on a NUMA node close 
to the one of the initial allocation is that the memory might be cleared 
on free by the core memory management and that should probably be done 
on a CPU close to it.




This change helps USWC GTT allocations on NUMA systems (dGPU) and AMD
APU platforms such as GFXIP9.4.3.

Signed-off-by: Rajneesh Bhardwaj 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 10 +-
  drivers/gpu/drm/ttm/ttm_device.c |  3 ++-
  2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 5757b9415e37..0d608441a112 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -370,7 +370,15 @@ static void ttm_bo_release(struct kref *kref)
spin_unlock(&bo->bdev->lru_lock);
  
  			INIT_WORK(&bo->delayed_delete, ttm_bo_delayed_delete);

-   queue_work(bdev->wq, &bo->delayed_delete);
+   /* Schedule the worker on the closest NUMA node,



  if no
+* CPUs are available, this falls back to any CPU core
+* available system wide.


Mentioning that is superfluous since everybody can look at the 
implementation and that a fallback is available for a function which 
doesn't return an error is obvious.



  This helps avoid the
+* bottleneck to clear memory in cases where the worker
+* is scheduled on a CPU which is remote to the node
+* where the memory is getting freed.
+*/


Rather write something like "This improves performance since system 
memory might be cleared on free and that is best done on a CPU core 
close to it."


Regards,
Christian.


+
+   queue_work_node(bdev->pool.nid, bdev->wq, 
&bo->delayed_delete);
return;
}
  
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c

index 43e27ab77f95..72b81a2ee6c7 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -213,7 +213,8 @@ int ttm_device_init(struct ttm_device *bdev, struct 
ttm_device_funcs *funcs,
bdev->funcs = funcs;
  
  	ttm_sys_man_init(bdev);

-   ttm_pool_init(&bdev->pool, dev, NUMA_NO_NODE, use_dma_alloc, use_dma32);
+
+   ttm_pool_init(&bdev->pool, dev, dev_to_node(dev), use_dma_alloc, 
use_dma32);
  
  	bdev->vma_manager = vma_manager;

spin_lock_init(&bdev->lru_lock);

Re: [PATCH v9 6/6] drm/i915/panelreplay: Debugfs support for panel replay

[Hogander, Jouni]

On Wed, 2023-11-08 at 12:53 +0530, Animesh Manna wrote:
> Add debugfs support which will print source and sink status
> per connector basis. Existing i915_psr_status and
> i915_psr_sink_status will be used to get the source and
> sink status of panel replay.
> 
> v1: Initial version. [rb-ed by Arun]
> v2: Added check for DP 2.0 and connector type in
> connector_debugfs_add().
> v3: Optimization and cosmetic changes. [Jouni]
> 
> Cc: Jouni Högander 
> Cc: Arun R Murthy 
> Cc: Jani Nikula 
> Reviewed-by: Arun R Murthy 
> Signed-off-by: Animesh Manna 

Reviewed-by: Jouni Högander 

> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 87 +-
> --
>  1 file changed, 63 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index ea292832ca47..b0e46fe4bfac 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -2865,12 +2865,19 @@ static int
> psr_get_status_and_error_status(struct intel_dp *intel_dp,
>  {
> struct drm_dp_aux *aux = &intel_dp->aux;
> int ret;
> +   unsigned int offset;
>  
> -   ret = drm_dp_dpcd_readb(aux, DP_PSR_STATUS, status);
> +   offset = intel_dp->psr.panel_replay_enabled ?
> +    DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS :
> DP_PSR_STATUS;
> +
> +   ret = drm_dp_dpcd_readb(aux, offset, status);
> if (ret != 1)
> return ret;
>  
> -   ret = drm_dp_dpcd_readb(aux, DP_PSR_ERROR_STATUS,
> error_status);
> +   offset = intel_dp->psr.panel_replay_enabled ?
> +    DP_PANEL_REPLAY_ERROR_STATUS : DP_PSR_ERROR_STATUS;
> +
> +   ret = drm_dp_dpcd_readb(aux, offset, error_status);
> if (ret != 1)
> return ret;
>  
> @@ -3091,7 +3098,7 @@ psr_source_status(struct intel_dp *intel_dp,
> struct seq_file *m)
> status = live_status[status_val];
> }
>  
> -   seq_printf(m, "Source PSR status: %s [0x%08x]\n", status,
> val);
> +   seq_printf(m, "Source PSR/PanelReplay status: %s [0x%08x]\n",
> status, val);
>  }
>  
>  static int intel_psr_status(struct seq_file *m, struct intel_dp
> *intel_dp)
> @@ -3104,18 +3111,22 @@ static int intel_psr_status(struct seq_file
> *m, struct intel_dp *intel_dp)
> bool enabled;
> u32 val;
>  
> -   seq_printf(m, "Sink support: %s", str_yes_no(psr-
> >sink_support));
> +   seq_printf(m, "Sink support: PSR = %s",
> +  str_yes_no(psr->sink_support));
> +
> if (psr->sink_support)
> seq_printf(m, " [0x%02x]", intel_dp->psr_dpcd[0]);
> -   seq_puts(m, "\n");
> +   seq_printf(m, ", Panel Replay = %s\n", str_yes_no(psr-
> >sink_panel_replay_support));
>  
> -   if (!psr->sink_support)
> +   if (!(psr->sink_support || psr->sink_panel_replay_support))
> return 0;
>  
> wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
> mutex_lock(&psr->lock);
>  
> -   if (psr->enabled)
> +   if (psr->panel_replay_enabled)
> +   status = "Panel Replay Enabled";
> +   else if (psr->enabled)
> status = psr->psr2_enabled ? "PSR2 enabled" : "PSR1
> enabled";
> else
> status = "disabled";
> @@ -3128,14 +3139,17 @@ static int intel_psr_status(struct seq_file
> *m, struct intel_dp *intel_dp)
> goto unlock;
> }
>  
> -   if (psr->psr2_enabled) {
> +   if (psr->panel_replay_enabled) {
> +   val = intel_de_read(dev_priv,
> TRANS_DP2_CTL(cpu_transcoder));
> +   enabled = val & TRANS_DP2_PANEL_REPLAY_ENABLE;
> +   } else if (psr->psr2_enabled) {
> val = intel_de_read(dev_priv,
> EDP_PSR2_CTL(cpu_transcoder));
> enabled = val & EDP_PSR2_ENABLE;
> } else {
> val = intel_de_read(dev_priv, psr_ctl_reg(dev_priv,
> cpu_transcoder));
> enabled = val & EDP_PSR_ENABLE;
> }
> -   seq_printf(m, "Source PSR ctl: %s [0x%08x]\n",
> +   seq_printf(m, "Source PSR/PanelReplay ctl: %s [0x%08x]\n",
>    str_enabled_disabled(enabled), val);
> psr_source_status(intel_dp, m);
> seq_printf(m, "Busy frontbuffer bits: 0x%08x\n",
> @@ -3273,6 +3287,16 @@ void intel_psr_debugfs_register(struct
> drm_i915_private *i915)
>     i915, &i915_edp_psr_status_fops);
>  }
>  
> +static const char *psr_mode_str(struct intel_dp *intel_dp)
> +{
> +   if (intel_dp->psr.panel_replay_enabled)
> +   return "PANEL-REPLAY";
> +   else if (intel_dp->psr.enabled)
> +   return "PSR";
> +
> +   return "unknown";
> +}
> +
>  static int i915_psr_sink_status_show(struct seq_file *m, void *data)
>  {
> struct intel_connector *connector = m->private;
> @@ -3287,12 +3311,19 @@ static int i915_psr_sink_status_show(struct
> seq_file *m, void 

Re: [PATCH] drm/amd/display: remove duplicated argument

[José Pekkarinen]

On 2023-10-30 15:54, Aurabindo Pillai wrote:

On 10/29/2023 5:39 AM, José Pekkarinen wrote:

Spotted by coccicheck, there is a redundant check for
v->SourcePixelFormat[k] != dm_444_16. This patch will
remove it. The corresponding output follows.

drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c:5130:86-122: 
duplicated argument to && or ||


Signed-off-by: José Pekkarinen 
---
  drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c | 2 
+-

  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c

index ad741a723c0e..3686f1e7de3a 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
@@ -5128,7 +5128,7 @@ void 
dml30_ModeSupportAndSystemConfigurationFull(struct display_mode_lib 
*mode_l

ViewportExceedsSurface = true;
		if (v->SourcePixelFormat[k] != dm_444_64 && 
v->SourcePixelFormat[k] != dm_444_32 && v->SourcePixelFormat[k] != 
dm_444_16
-&& v->SourcePixelFormat[k] != dm_444_16 && 
v->SourcePixelFormat[k] != dm_444_8 && v->SourcePixelFormat[k] != 
dm_rgbe) {
+&& v->SourcePixelFormat[k] != dm_444_8 && v->SourcePixelFormat[k] 
!= dm_rgbe) {
  			if (v->ViewportWidthChroma[k] > v->SurfaceWidthC[k] || 
v->ViewportHeightChroma[k] > v->SurfaceHeightC[k]) {

ViewportExceedsSurface = true;
}


Thanks for catching.

Reviewed-by: Aurabindo Pillai 


Sorry to bring this up, I just wanted to check whether this
has been applied in the following pulls or not.

Thanks!

José.

Re: [RFC v4 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem

[Aravind Iddamsetty]

On 07/11/23 11:00, Lazar, Lijo wrote:
>
>
> On 11/1/2023 1:36 PM, Aravind Iddamsetty wrote:
>>
>> On 30/10/23 20:41, Lazar, Lijo wrote:
>>>
>>>
>>> On 10/30/2023 11:49 AM, Aravind Iddamsetty wrote:

 On 26/10/23 15:34, Lazar, Lijo wrote:

 Hi Lijo,

 Thank you for your comments.

>
>
> On 10/23/2023 8:59 PM, Alex Deucher wrote:
>> On Fri, Oct 20, 2023 at 7:42 PM Aravind Iddamsetty
>>  wrote:
>>>
>>> Our hardware supports RAS(Reliability, Availability, Serviceability) by
>>> reporting the errors to the host, which the KMD processes and exposes a
>>> set of error counters which can be used by observability tools to take
>>> corrective actions or repairs. Traditionally there were being exposed
>>> via PMU (for relative counters) and sysfs interface (for absolute
>>> value) in our internal branch. But, due to the limitations in this
>>> approach to use two interfaces and also not able to have an event based
>>> reporting or configurability, an alternative approach to try netlink
>>> was suggested by community for drm subsystem wide UAPI for RAS and
>>> telemetry as discussed in [1].
>>>
>>> This [1] is the inspiration to this series. It uses the generic
>>> netlink(genl) family subsystem and exposes a set of commands that can
>>> be used by every drm driver, the framework provides a means to have
>>> custom commands too. Each drm driver instance in this example xe driver
>>> instance registers a family and operations to the genl subsystem through
>>> which it enumerates and reports the error counters. An event based
>>> notification is also supported to which userpace can subscribe to and
>>> be notified when any error occurs and read the error counter this avoids
>>> continuous polling on error counter. This can also be extended to
>>> threshold based notification.
>
> The commands used seems very limited. In AMD SOCs, IP blocks, instances 
> of IP blocks, block types which support RAS will change across 
> generations.
>
> This series has a single command to query the counters supported. Within 
> that it seems to assign unique ids for every combination of error type, 
> IP block type and then another for each instance. Not sure how good this 
> kind of approach is for an end user. The Ids won't necessarily the stay 
> the same across multiple generations. Users will generally be interested 
> in specific IP blocks.

 Exactly the IDs are UAPI and won't change once defined for a platform and 
 any new SKU or platform will add on top of existing ones. Userspace can 
 include the header and use the defines. The query is used to know what all 
 errors exists on a platform and userspace can process the IDs of IP block 
 of interest. I believe even if we list block wise a query will be needed 
 without which userspace wouldn't know which blocks exist on a platform.

>>>
>>> What I meant is - assigning an id for every combination of IP block/ 
>>> instance number/error type is not maintainable across different SOCs.
>>>
>>> Instead, can we have  something like -
>>>  Query -> returns IP block ids, number of instances, error types 
>>> supported by each IP block.
>>>  Read Error -> IP block id | Instance number /Instance ALL | Error type 
>>> id/Error type ALL.
>>
>> Hi Lijo,
>>
>> Would you please elaborate more on what is the issue you fore see with the 
>> maintainability. But I have a query on the model suggested
>>
>> This might work well with user input based tools, but don't think it suits 
>> if we want to periodically read a particular counter.
>>
>> The inspiration to have ID for each is taken from PMU subsystem where every 
>> event has an ID and a flat list so no multiple queries and we can read them 
>> individually or group together
>> which can be achieved via READ_MULTI command I proposed earlier.
>>
>
> The problem is mainly with maintaining a static list including all ip_id | 
> instance | err_type combinations.  Instead, preference is for client to query 
> the capabilities -> instance/error types supported and then use that info 
> later to fetch error info.
>
> Capability query could return something like ip block, total instance 
> available and error types supported. This doesn't require to maintain an ID 
> list for each combination.
>
> The instances per SOC could be variable. For ex: it's not required that all 
> SKUs of your SOC type to have have ss0-ss3 HBMs. For the same SOC type or for 
> new SOC type, it could be more or less.
>
> Roughly something like ..
>
> enum ip_block_id
> {
> block1,
> block2,
> block3,
> 
> block_all
> }
>
> enum ip_sub_block_id (if required)
> {
> sub_block1,
> sub_block2,
> 
> sub_block_all
> }
>
> #define INSTANCE_ALL  -1
>
> enum ras_error_type
> {
> correctable,
> uncorrectable,
> de

Re: [PATCH] drm: i915: Adapt to -Walloc-size

[Jani Nikula]

On Tue, 07 Nov 2023, Sam James  wrote:
> GCC 14 introduces a new -Walloc-size included in -Wextra which errors out
> like:
> ```
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c: In function 
> ‘eb_copy_relocations’:
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1681:24: error: allocation of 
> insufficient size ‘1’ for type ‘struct drm_i915_gem_relocation_entry’ with 
> size ‘32’ [-Werror=alloc-size]
>  1681 | relocs = kvmalloc_array(size, 1, GFP_KERNEL);
>   |^
>
> ```
>
> So, just swap the number of members and size arguments to match the 
> prototype, as
> we're initialising 1 element of size `size`. GCC then sees we're not
> doing anything wrong.
>
> Signed-off-by: Sam James 

The short answer,

Reviewed-by: Jani Nikula 

but please read on.

> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 683fd8d3151c..45b9d9e34b8b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1678,7 +1678,7 @@ static int eb_copy_relocations(const struct 
> i915_execbuffer *eb)
>   urelocs = u64_to_user_ptr(eb->exec[i].relocs_ptr);
>   size = nreloc * sizeof(*relocs);
>  
> - relocs = kvmalloc_array(size, 1, GFP_KERNEL);
> + relocs = kvmalloc_array(1, size, GFP_KERNEL);

Based on the patch context, we should really be calling:

kvmalloc_array(nreloc, sizeof(*relocs), GFP_KERNEL);

and we'd get mul overflow checks too.

However, the code below also needs size, unless it's refactored to
operate on multiples of sizeof(*relocs) and it all gets a bit annoying.

Maybe there's a better way, but for the short term the patch at hand is
no worse than what we currently have, and it'll silence the warning, so
let's go with this.


>   if (!relocs) {
>   err = -ENOMEM;
>   goto err;

-- 
Jani Nikula, Intel

Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Pekka Paalanen]

On Tue, 7 Nov 2023 11:58:26 -0500
Harry Wentland  wrote:

> On 2023-11-07 04:55, Pekka Paalanen wrote:
> > On Mon, 6 Nov 2023 11:19:27 -0500
> > Harry Wentland  wrote:
> >   
> >> On 2023-10-20 06:36, Pekka Paalanen wrote:  
> >>> On Thu, 19 Oct 2023 10:56:40 -0400
> >>> Harry Wentland  wrote:
> >>> 
>  On 2023-10-10 12:13, Melissa Wen wrote:
> > O 09/08, Harry Wentland wrote:  
> >> Signed-off-by: Harry Wentland 
> >>>
> >>> ...
> >>> 
> > Also, with this new plane API in place, I understand that we will
> > already need think on how to deal with the mixing between old drm color
> > properties (color encoding and color range) and these new way of setting
> > plane color properties. IIUC, Pekka asked a related question about it
> > when talking about CRTC automatic RGB->YUV (?) 
> >   
> 
>  We'll still need to confirm whether we'll want to deprecate these
>  existing properties. If we do that we'd want a client prop. Things
>  should still work without deprecating them, if drivers just pick up
>  after the initial encoding and range CSC.
> 
>  But realistically it might be better to deprecate them and turn them
>  into explicit colorops.
> >>>
> >>> The existing properties would need to be explicitly reflected in the
> >>> new pipelines anyway, otherwise there would always be doubt at which
> >>> point of a pipeline the old properties apply, and they might even
> >>> need to change positions between pipelines.
> >>>
> >>> I think it is simply easier to just hide all old color related
> >>> properties when userspace sets the client-cap to enable pipelines. The
> >>> problem is to make sure to hide all old properties on all drivers that
> >>> support the client-cap.
> >>>
> >>> As a pipeline must be complete (describe everything that happens to
> >>> pixel values), it's going to be a flag day per driver.
> >>>
> >>> Btw. the plane FB YUV->RGB conversion needs a colorop in every pipeline
> >>> as well. Maybe it's purely informative and non-configurable, keyed by
> >>> FB pixel format, but still.
> >>>
> >>> We also need a colorop to represent sample filtering, e.g. bilinear,
> >>> like I think Sebastian may have mentioned in the past. Everything
> >>> before the sample filter happens "per tap" as Joshua Ashton put it, and
> >>> everything after it happens on the sample that was computed as a
> >>> weighted average of the filter tap inputs (texels).
> >>>
> >>> There could be colorops other than sample filtering that operate on
> >>> more than one sample at a time, like blur or sharpness. There could
> >>> even be colorops that change the image size like adding padding that
> >>> the following colorop hardware requires, and then yet another colorop
> >>> that clips that padding away. For an example, see
> >>> https://lists.freedesktop.org/archives/dri-devel/2023-October/427015.html
> >>>
> >>> If that padding and its color can affect the pipeline results of the
> >>> pixels near the padding (e.g. some convolution is applied with them,
> >>> which may be the reason why padding is necessary to begin with), then
> >>> it would be best to model it.
> >>> 
> >>
> >> I hear you but I'm also somewhat shying away from defining this at this 
> >> point.  
> > 
> > Would you define them before the new UAPI is released though?
> > 
> > I agree there is no need to have them in this patch series, but I think
> > we'd hit the below problems if the UAPI is released without them.
> >   
> >> There are already too many things that need to happen and I will focus on 
> >> the
> >> actual color blocks (LUTs, matrices) first. We'll always be able to add a 
> >> new
> >> (read-only) colorop type to define scaling and tap behavior at any point 
> >> and
> >> a client is free to ignore a color pipeline if it doesn't find any 
> >> tap/scale
> >> info in it.  
> > 
> > How would userspace know to look for tap/scale info, if there is no
> > upstream definition even on paper?
> >   
> 
> So far OSes did not care about this. Whether that's good or bad is
> something everyone can answer for themselves.
> 
> If you write a compositor and really need this you can just ignore
> color pipelines that don't have this, i.e., you'll probably want
> to wait with implementing color pipeline support until you have what
> you need from DRM/KMS.
> 
> This is not to say I don't want to have support for Weston. But I'm
> wondering if we place too much importance on getting every little
> thing figured out whereas we could be making forward progress and
> address more aspects of a color pipeline in the future. There is a
> reason gamescope has made a huge difference in driving the color
> management work forward.
> 
> > And the opposite case, if someone writes userspace without tap/scale
> > colorops, and then drivers add those, and there is no pipeline without
> > them, because they always exist. Would that userspace disregard all
> > those pipelines be

[PATCH 00/17] dt-bindings: samsung: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Hi,

Merging
===
I propose to take entire patchset through my tree (Samsung SoC), because:
1. Next cycle two new SoCs will be coming (Google GS101 and ExynosAutov920), so
   they will touch the same lines in some of the DT bindings (not all, though).
   It is reasonable for me to take the bindings for the new SoCs, to have clean
   `make dtbs_check` on the new DTS.
2. Having it together helps me to have clean `make dtbs_check` within my tree
   on the existing DTS.
3. No drivers are affected by this change.
4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
   follow up patchsets.

If folks agree, please kindly Ack the patches.

Description
===
Samsung Exynos SoCs reuse several devices from older designs, thus historically
we kept the old (block's) compatible only.  This works fine and there is no bug
here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like compatibles.
This will also help reviews of new code using existing DTS as template.  No
functional impact on Linux drivers behavior.

Future
==
If reasonable, I will do similar work for Tesla FSD and ARMv7/ARM32 Exynos
bindings and DTS.

Best regards,
Krzysztof

Krzysztof Kozlowski (17):
  dt-bindings: hwinfo: samsung,exynos-chipid: add specific compatibles
for existing SoC
  dt-bindings: i2c: exynos5: add specific compatibles for existing SoC
  dt-bindings: i2c: samsung,s3c2410-i2c: add specific compatibles for
existing SoC
  dt-bindings: mmc: samsung,exynos-dw-mshc: add specific compatibles for
existing SoC
  dt-bindings: pinctrl: samsung: add specific compatibles for existing
SoC
  dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoC
  dt-bindings: serial: samsung: add specific compatibles for existing
SoC
  dt-bindings: samsung: exynos-pmu: add specific compatibles for
existing SoC
  dt-bindings: gpu: arm,mali-midgard: add specific compatibles for
existing Exynos SoC
  dt-bindings: iio: samsung,exynos-adc: add specific compatibles for
existing SoC
  ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing
SoC
  dt-bindings: pwm: samsung: add specific compatibles for existing SoC
  arm64: dts: exynos5433: add specific compatibles to several blocks
  arm64: dts: exynos7: add specific compatibles to several blocks
  arm64: dts: exynos7885: add specific compatibles to several blocks
  arm64: dts: exynos850: add specific compatibles to several blocks
  arm64: dts: exynosautov9: add specific compatibles to several blocks

 .../bindings/gpu/arm,mali-midgard.yaml|  5 ++
 .../hwinfo/samsung,exynos-chipid.yaml | 17 +-
 .../devicetree/bindings/i2c/i2c-exynos5.yaml  | 10 +++-
 .../bindings/i2c/samsung,s3c2410-i2c.yaml | 22 ---
 .../bindings/iio/adc/samsung,exynos-adc.yaml  | 29 +
 .../mfd/samsung,exynos5433-lpass.yaml |  2 +-
 .../bindings/mmc/samsung,exynos-dw-mshc.yaml  | 25 +---
 .../samsung,pinctrl-wakeup-interrupt.yaml | 24 +---
 .../bindings/pinctrl/samsung,pinctrl.yaml |  3 +-
 .../devicetree/bindings/pwm/pwm-samsung.yaml  |  2 +
 .../devicetree/bindings/rtc/s3c-rtc.yaml  |  5 ++
 .../bindings/serial/samsung_uart.yaml | 14 -
 .../bindings/soc/samsung/exynos-pmu.yaml  |  6 ++
 .../bindings/soc/samsung/exynos-usi.yaml  |  2 +-
 .../bindings/sound/samsung-i2s.yaml   | 19 +++---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi| 60 ---
 arch/arm64/boot/dts/exynos/exynos7.dtsi   | 18 +++---
 arch/arm64/boot/dts/exynos/exynos7885.dtsi| 45 +-
 arch/arm64/boot/dts/exynos/exynos850.dtsi | 34 ++-
 arch/arm64/boot/dts/exynos/exynosautov9.dtsi  |  6 +-
 20 files changed, 233 insertions(+), 115 deletions(-)

-- 
2.34.1

[PATCH 01/17] dt-bindings: hwinfo: samsung, exynos-chipid: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../bindings/hwinfo/samsung,exynos-chipid.yaml  | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml 
b/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml
index 95cbdcb56efe..45f3d468db7c 100644
--- a/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml
+++ b/Documentation/devicetree/bindings/hwinfo/samsung,exynos-chipid.yaml
@@ -11,9 +11,20 @@ maintainers:
 
 properties:
   compatible:
-enum:
-  - samsung,exynos4210-chipid
-  - samsung,exynos850-chipid
+oneOf:
+  - enum:
+  - samsung,exynos4210-chipid
+  - samsung,exynos850-chipid
+  - items:
+  - enum:
+  - samsung,exynos5433-chipid
+  - samsung,exynos7-chipid
+  - const: samsung,exynos4210-chipid
+  - items:
+  - enum:
+  - samsung,exynos7885-chipid
+  - samsung,exynosautov9-chipid
+  - const: samsung,exynos850-chipid
 
   reg:
 maxItems: 1
-- 
2.34.1

[PATCH 02/17] dt-bindings: i2c: exynos5: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml | 10 +-
 .../devicetree/bindings/soc/samsung/exynos-usi.yaml|  2 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml 
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
index 3e52a0db6c41..c1f5d2cb7709 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml
@@ -25,7 +25,15 @@ properties:
   - samsung,exynos5250-hsi2c# Exynos5250 and Exynos5420
   - samsung,exynos5260-hsi2c# Exynos5260
   - samsung,exynos7-hsi2c   # Exynos7
-  - samsung,exynosautov9-hsi2c  # ExynosAutoV9 and Exynos850
+  - samsung,exynosautov9-hsi2c
+  - items:
+  - enum:
+  - samsung,exynos5433-hsi2c
+  - const: samsung,exynos7-hsi2c
+  - items:
+  - enum:
+  - samsung,exynos850-hsi2c
+  - const: samsung,exynosautov9-hsi2c
   - const: samsung,exynos5-hsi2c# Exynos5250 and Exynos5420
 deprecated: true
 
diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml 
b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
index a6836904a4f8..5b7ab69546c4 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml
@@ -155,7 +155,7 @@ examples:
 };
 
 hsi2c_0: i2c@1382 {
-compatible = "samsung,exynosautov9-hsi2c";
+compatible = "samsung,exynos850-hsi2c", 
"samsung,exynosautov9-hsi2c";
 reg = <0x1382 0xc0>;
 interrupts = ;
 #address-cells = <1>;
-- 
2.34.1

[PATCH 03/17] dt-bindings: i2c: samsung, s3c2410-i2c: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../bindings/i2c/samsung,s3c2410-i2c.yaml | 22 ---
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml 
b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
index b204e35e4f8d..1303502cf265 100644
--- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
@@ -11,14 +11,20 @@ maintainers:
 
 properties:
   compatible:
-enum:
-  - samsung,s3c2410-i2c
-  - samsung,s3c2440-i2c
-# For s3c2440-like I2C used inside HDMIPHY block found on several SoCs:
-  - samsung,s3c2440-hdmiphy-i2c
-# For s3c2440-like I2C used as a host to SATA PHY controller on an
-# internal bus:
-  - samsung,exynos5-sata-phy-i2c
+oneOf:
+  - enum:
+  - samsung,s3c2410-i2c
+  - samsung,s3c2440-i2c
+# For s3c2440-like I2C used inside HDMIPHY block found on several 
SoCs:
+  - samsung,s3c2440-hdmiphy-i2c
+# For s3c2440-like I2C used as a host to SATA PHY controller on an
+# internal bus:
+  - samsung,exynos5-sata-phy-i2c
+  - items:
+  - enum:
+  - samsung,exynos7885-i2c
+  - samsung,exynos850-i2c
+  - const: samsung,s3c2440-i2c
 
   '#address-cells':
 const: 1
-- 
2.34.1

[PATCH 04/17] dt-bindings: mmc: samsung, exynos-dw-mshc: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

While re-indenting the first enum, put also axis,artpec8-dw-mshc in
alphabetical order.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../bindings/mmc/samsung,exynos-dw-mshc.yaml  | 25 ---
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml 
b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
index 6ee78a38bd74..5fe65795f796 100644
--- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
@@ -14,15 +14,22 @@ maintainers:
 
 properties:
   compatible:
-enum:
-  - samsung,exynos4210-dw-mshc
-  - samsung,exynos4412-dw-mshc
-  - samsung,exynos5250-dw-mshc
-  - samsung,exynos5420-dw-mshc
-  - samsung,exynos5420-dw-mshc-smu
-  - samsung,exynos7-dw-mshc
-  - samsung,exynos7-dw-mshc-smu
-  - axis,artpec8-dw-mshc
+oneOf:
+  - enum:
+  - axis,artpec8-dw-mshc
+  - samsung,exynos4210-dw-mshc
+  - samsung,exynos4412-dw-mshc
+  - samsung,exynos5250-dw-mshc
+  - samsung,exynos5420-dw-mshc
+  - samsung,exynos5420-dw-mshc-smu
+  - samsung,exynos7-dw-mshc
+  - samsung,exynos7-dw-mshc-smu
+  - items:
+  - enum:
+  - samsung,exynos5433-dw-mshc-smu
+  - samsung,exynos7885-dw-mshc-smu
+  - samsung,exynos850-dw-mshc-smu
+  - const: samsung,exynos7-dw-mshc-smu
 
   reg:
 maxItems: 1
-- 
2.34.1

[PATCH 05/17] dt-bindings: pinctrl: samsung: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../samsung,pinctrl-wakeup-interrupt.yaml | 24 ---
 .../bindings/pinctrl/samsung,pinctrl.yaml |  3 ++-
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
 
b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
index 1de91a51234d..1c07af24d6cf 100644
--- 
a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
+++ 
b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml
@@ -28,15 +28,21 @@ description: |
 
 properties:
   compatible:
-enum:
-  - samsung,s3c2410-wakeup-eint
-  - samsung,s3c2412-wakeup-eint
-  - samsung,s3c64xx-wakeup-eint
-  - samsung,s5pv210-wakeup-eint
-  - samsung,exynos4210-wakeup-eint
-  - samsung,exynos7-wakeup-eint
-  - samsung,exynos850-wakeup-eint
-  - samsung,exynosautov9-wakeup-eint
+oneOf:
+  - enum:
+  - samsung,s3c2410-wakeup-eint
+  - samsung,s3c2412-wakeup-eint
+  - samsung,s3c64xx-wakeup-eint
+  - samsung,s5pv210-wakeup-eint
+  - samsung,exynos4210-wakeup-eint
+  - samsung,exynos7-wakeup-eint
+  - samsung,exynos850-wakeup-eint
+  - samsung,exynosautov9-wakeup-eint
+  - items:
+  - enum:
+  - samsung,exynos5433-wakeup-eint
+  - samsung,exynos7885-wakeup-eint
+  - const: samsung,exynos7-wakeup-eint
 
   interrupts:
 description:
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 26614621774a..7509dc36af93 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -313,7 +313,8 @@ examples:
 pinctrl-0 = <&initial_alive>;
 
 wakeup-interrupt-controller {
-compatible = "samsung,exynos7-wakeup-eint";
+compatible = "samsung,exynos5433-wakeup-eint",
+ "samsung,exynos7-wakeup-eint";
 interrupts = ;
 };
 
-- 
2.34.1

[PATCH 06/17] dt-bindings: rtc: s3c-rtc: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 Documentation/devicetree/bindings/rtc/s3c-rtc.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml 
b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
index d51b236939bf..bf4e11d6dffb 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.yaml
@@ -17,6 +17,11 @@ properties:
   - samsung,s3c2416-rtc
   - samsung,s3c2443-rtc
   - samsung,s3c6410-rtc
+  - items:
+  - enum:
+  - samsung,exynos7-rtc
+  - samsung,exynos850-rtc
+  - const: samsung,s3c6410-rtc
   - const: samsung,exynos3250-rtc
 deprecated: true
 
-- 
2.34.1

[PATCH 07/17] dt-bindings: serial: samsung: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Re-shuffle also the entries in compatibles, so the one-compatible-enum
is the first.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../devicetree/bindings/serial/samsung_uart.yaml   | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml 
b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
index ac60ab1e35e3..0d0215b23ab7 100644
--- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml
+++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml
@@ -18,9 +18,6 @@ description: |+
 properties:
   compatible:
 oneOf:
-  - items:
-  - const: samsung,exynosautov9-uart
-  - const: samsung,exynos850-uart
   - enum:
   - apple,s5l-uart
   - axis,artpec8-uart
@@ -29,6 +26,17 @@ properties:
   - samsung,exynos4210-uart
   - samsung,exynos5433-uart
   - samsung,exynos850-uart
+  - items:
+  - enum:
+  - samsung,exynos7-uart
+  - const: samsung,exynos4210-uart
+  - items:
+  - enum:
+  - samsung,exynos7885-uart
+  - const: samsung,exynos5433-uart
+  - items:
+  - const: samsung,exynosautov9-uart
+  - const: samsung,exynos850-uart
 
   reg:
 maxItems: 1
-- 
2.34.1

[PATCH 08/17] dt-bindings: samsung: exynos-pmu: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../devicetree/bindings/soc/samsung/exynos-pmu.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml 
b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
index e1d716df5dfa..6492e92586d9 100644
--- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
+++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
@@ -48,6 +48,12 @@ properties:
   - samsung,exynos850-pmu
   - samsung-s5pv210-pmu
   - const: syscon
+  - items:
+  - enum:
+  - samsung,exynos7885-pmu
+  - samsung,exynosautov9-pmu
+  - const: samsung,exynos7-pmu
+  - const: syscon
   - items:
   - enum:
   - samsung,exynos3250-pmu
-- 
2.34.1

[PATCH 10/17] dt-bindings: iio: samsung, exynos-adc: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../bindings/iio/adc/samsung,exynos-adc.yaml  | 29 +++
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml 
b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
index 582d0a03b814..4e40f6bed5db 100644
--- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml
@@ -11,18 +11,23 @@ maintainers:
 
 properties:
   compatible:
-enum:
-  - samsung,exynos-adc-v1 # Exynos5250
-  - samsung,exynos-adc-v2
-  - samsung,exynos3250-adc
-  - samsung,exynos4212-adc# Exynos4212 and Exynos4412
-  - samsung,exynos7-adc
-  - samsung,s3c2410-adc
-  - samsung,s3c2416-adc
-  - samsung,s3c2440-adc
-  - samsung,s3c2443-adc
-  - samsung,s3c6410-adc
-  - samsung,s5pv210-adc
+oneOf:
+  - enum:
+  - samsung,exynos-adc-v1 # Exynos5250
+  - samsung,exynos-adc-v2
+  - samsung,exynos3250-adc
+  - samsung,exynos4212-adc# Exynos4212 and Exynos4412
+  - samsung,exynos7-adc
+  - samsung,s3c2410-adc
+  - samsung,s3c2416-adc
+  - samsung,s3c2440-adc
+  - samsung,s3c2443-adc
+  - samsung,s3c6410-adc
+  - samsung,s5pv210-adc
+  - items:
+  - enum:
+  - samsung,exynos5433-adc
+  - const: samsung,exynos7-adc
 
   reg:
 maxItems: 1
-- 
2.34.1

[PATCH 09/17] dt-bindings: gpu: arm, mali-midgard: add specific compatibles for existing Exynos SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml 
b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
index ca02baba5526..0801da33a385 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml
@@ -40,6 +40,11 @@ properties:
   - rockchip,rk3288-mali
   - samsung,exynos5433-mali
   - const: arm,mali-t760
+  - items:
+  - enum:
+  - samsung,exynos7-mali
+  - const: samsung,exynos5433-mali
+  - const: arm,mali-t760
   - items:
   - enum:
   - rockchip,rk3399-mali
-- 
2.34.1

[PATCH 11/17] ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 .../mfd/samsung,exynos5433-lpass.yaml |  2 +-
 .../bindings/sound/samsung-i2s.yaml   | 19 ---
 2 files changed, 13 insertions(+), 8 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml 
b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml
index b97b06848729..f154103f32cc 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml
+++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml
@@ -85,7 +85,7 @@ examples:
 };
 
 i2s@1144 {
-compatible = "samsung,exynos7-i2s";
+compatible = "samsung,exynos5433-i2s", "samsung,exynos7-i2s";
 reg = <0x1144 0x100>;
 dmas = <&adma 0>, <&adma 2>;
 dma-names = "tx", "rx";
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml 
b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
index 30b3b6e9824b..f45f73b5056d 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml
@@ -44,13 +44,18 @@ properties:
   frequencies supported by Exynos7 I2S and 7.1 channel TDM support
   for playback and capture TDM (Time division multiplexing) to allow
   transfer of multiple channel audio data on single data line.
-enum:
-  - samsung,s3c6410-i2s
-  - samsung,s5pv210-i2s
-  - samsung,exynos5420-i2s
-  - samsung,exynos7-i2s
-  - samsung,exynos7-i2s1
-  - tesla,fsd-i2s
+oneOf:
+  - enum:
+  - samsung,s3c6410-i2s
+  - samsung,s5pv210-i2s
+  - samsung,exynos5420-i2s
+  - samsung,exynos7-i2s
+  - samsung,exynos7-i2s1
+  - tesla,fsd-i2s
+  - items:
+  - enum:
+  - samsung,exynos5433-i2s
+  - const: samsung,exynos7-i2s
 
   '#address-cells':
 const: 1
-- 
2.34.1

[PATCH 12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

Samsung Exynos SoC reuses several devices from older designs, thus
historically we kept the old (block's) compatible only.  This works fine
and there is no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to each SoC in front of all old-SoC-like
compatibles.

Signed-off-by: Krzysztof Kozlowski 

---

I propose to take the patch through Samsung SoC (me). See cover letter
for explanation.
---
 Documentation/devicetree/bindings/pwm/pwm-samsung.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml 
b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
index 2162f661ed5a..89a3875cb50a 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml
@@ -29,6 +29,8 @@ properties:
   - samsung,exynos4210-pwm  # 32-bit, Exynos
   - items:
   - enum:
+  - samsung,exynos5433-pwm
+  - samsung,exynos7-pwm
   - samsung,exynosautov9-pwm
   - const: samsung,exynos4210-pwm
 
-- 
2.34.1

[PATCH 13/17] arm64: dts: exynos5433: add specific compatibles to several blocks

[Krzysztof Kozlowski]

Exynos5433 reuses several devices from older designs, thus historically
we kept the old (block's) compatible only.  This works fine and there is
no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to Exynos5433 in front of all old-SoC-like
compatibles.  This will also help reviews of new code using existing
DTS as template.  No functional impact on Linux drivers behavior.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 60 ++
 1 file changed, 39 insertions(+), 21 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 91ae0462a706..7fbbec04bff0 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -361,7 +361,8 @@ soc: soc@0 {
ranges = <0x0 0x0 0x0 0x1800>;
 
chipid@1000 {
-   compatible = "samsung,exynos4210-chipid";
+   compatible = "samsung,exynos5433-chipid",
+"samsung,exynos4210-chipid";
reg = <0x1000 0x100>;
};
 
@@ -850,7 +851,8 @@ pinctrl_alive: pinctrl@1058 {
reg = <0x1058 0x1a20>, <0x1109 0x100>;
 
wakeup-interrupt-controller {
-   compatible = "samsung,exynos7-wakeup-eint";
+   compatible = "samsung,exynos5433-wakeup-eint",
+"samsung,exynos7-wakeup-eint";
interrupts = ;
};
};
@@ -1546,7 +1548,7 @@ spi_4: spi@14d0 {
};
 
adc: adc@14d1 {
-   compatible = "samsung,exynos7-adc";
+   compatible = "samsung,exynos5433-adc", 
"samsung,exynos7-adc";
reg = <0x14d1 0x100>;
interrupts = ;
clock-names = "adc";
@@ -1556,7 +1558,7 @@ adc: adc@14d1 {
};
 
i2s1: i2s@14d6 {
-   compatible = "samsung,exynos7-i2s";
+   compatible = "samsung,exynos5433-i2s", 
"samsung,exynos7-i2s";
reg = <0x14d6 0x100>;
dmas = <&pdma0 31>, <&pdma0 30>;
dma-names = "tx", "rx";
@@ -1571,7 +1573,7 @@ i2s1: i2s@14d6 {
};
 
pwm: pwm@14dd {
-   compatible = "samsung,exynos4210-pwm";
+   compatible = "samsung,exynos5433-pwm", 
"samsung,exynos4210-pwm";
reg = <0x14dd 0x100>;
interrupts = ,
 ,
@@ -1586,7 +1588,8 @@ pwm: pwm@14dd {
};
 
hsi2c_0: i2c@14e4 {
-   compatible = "samsung,exynos7-hsi2c";
+   compatible = "samsung,exynos5433-hsi2c",
+"samsung,exynos7-hsi2c";
reg = <0x14e4 0x1000>;
interrupts = ;
#address-cells = <1>;
@@ -1599,7 +1602,8 @@ hsi2c_0: i2c@14e4 {
};
 
hsi2c_1: i2c@14e5 {
-   compatible = "samsung,exynos7-hsi2c";
+   compatible = "samsung,exynos5433-hsi2c",
+"samsung,exynos7-hsi2c";
reg = <0x14e5 0x1000>;
interrupts = ;
#address-cells = <1>;
@@ -1612,7 +1616,8 @@ hsi2c_1: i2c@14e5 {
};
 
hsi2c_2: i2c@14e6 {
-   compatible = "samsung,exynos7-hsi2c";
+   compatible = "samsung,exynos5433-hsi2c",
+"samsung,exynos7-hsi2c";
reg = <0x14e6 0x1000>;
interrupts = ;
#address-cells = <1>;
@@ -1625,7 +1630,8 @@ hsi2c_2: i2c@14e6 {
};
 
hsi2c_3: i2c@14e7 {
-   compatible = "samsung,exynos7-hsi2c";
+   compatible = "samsung,exynos5433-hsi2c",
+"samsung,exynos7-hsi2c";
reg = <0x14e7 0x1000>;
interrupts = ;
#address-cells = <1>;
@@ -1638,7 +1644,8 @@ hsi2c_3: i2c@14e7 {
};
 
hsi2c_4: i2c@14ec {
-   compatible = "samsung,exynos7-hsi2c";
+   compatible = "samsung,exynos5433-hsi2c",
+  

[PATCH 14/17] arm64: dts: exynos7: add specific compatibles to several blocks

[Krzysztof Kozlowski]

Exynos7 reuses several devices from older designs, thus historically
we kept the old (block's) compatible only.  This works fine and there is
no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to Exynos7 in front of all old-SoC-like
compatibles.  This will also help reviews of new code using existing
DTS as template.  No functional impact on Linux drivers behavior.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos7.dtsi | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 6ed80ddf3369..9cb6bd61262e 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -128,7 +128,8 @@ soc: soc@0 {
ranges = <0 0 0 0x1800>;
 
chipid@1000 {
-   compatible = "samsung,exynos4210-chipid";
+   compatible = "samsung,exynos7-chipid",
+"samsung,exynos4210-chipid";
reg = <0x1000 0x100>;
};
 
@@ -279,7 +280,7 @@ clock_fsys1: clock-controller@156e {
};
 
serial_0: serial@1363 {
-   compatible = "samsung,exynos4210-uart";
+   compatible = "samsung,exynos7-uart", 
"samsung,exynos4210-uart";
reg = <0x1363 0x100>;
interrupts = ;
clocks = <&clock_peric0 PCLK_UART0>,
@@ -289,7 +290,7 @@ serial_0: serial@1363 {
};
 
serial_1: serial@14c2 {
-   compatible = "samsung,exynos4210-uart";
+   compatible = "samsung,exynos7-uart", 
"samsung,exynos4210-uart";
reg = <0x14c2 0x100>;
interrupts = ;
clocks = <&clock_peric1 PCLK_UART1>,
@@ -299,7 +300,7 @@ serial_1: serial@14c2 {
};
 
serial_2: serial@14c3 {
-   compatible = "samsung,exynos4210-uart";
+   compatible = "samsung,exynos7-uart", 
"samsung,exynos4210-uart";
reg = <0x14c3 0x100>;
interrupts = ;
clocks = <&clock_peric1 PCLK_UART2>,
@@ -309,7 +310,7 @@ serial_2: serial@14c3 {
};
 
serial_3: serial@14c4 {
-   compatible = "samsung,exynos4210-uart";
+   compatible = "samsung,exynos7-uart", 
"samsung,exynos4210-uart";
reg = <0x14c4 0x100>;
interrupts = ;
clocks = <&clock_peric1 PCLK_UART3>,
@@ -539,7 +540,7 @@ pmu_system_controller: system-controller@105c {
};
 
rtc: rtc@1059 {
-   compatible = "samsung,s3c6410-rtc";
+   compatible = "samsung,exynos7-rtc", 
"samsung,s3c6410-rtc";
reg = <0x1059 0x100>;
interrupts = ,
 ;
@@ -559,7 +560,8 @@ watchdog: watchdog@101d {
};
 
gpu: gpu@14ac {
-   compatible = "samsung,exynos5433-mali", "arm,mali-t760";
+   compatible = "samsung,exynos7-mali",
+"samsung,exynos5433-mali", "arm,mali-t760";
reg = <0x14ac 0x5000>;
interrupts = ,
 ,
@@ -619,7 +621,7 @@ adc: adc@1362 {
};
 
pwm: pwm@136c {
-   compatible = "samsung,exynos4210-pwm";
+   compatible = "samsung,exynos7-pwm", 
"samsung,exynos4210-pwm";
reg = <0x136c 0x100>;
interrupts = ,
 ,
-- 
2.34.1

[PATCH 15/17] arm64: dts: exynos7885: add specific compatibles to several blocks

[Krzysztof Kozlowski]

Exynos7885 reuses several devices from older designs, thus historically
we kept the old (block's) compatible only.  This works fine and there is
no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to Exynos7885 in front of all old-SoC-like
compatibles.  This will also help reviews of new code using existing
DTS as template.  No functional impact on Linux drivers behavior.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos7885.dtsi | 45 ++
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos7885.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7885.dtsi
index d69fc2392bd0..008228fb319a 100644
--- a/arch/arm64/boot/dts/exynos/exynos7885.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7885.dtsi
@@ -172,7 +172,8 @@ soc: soc@0 {
ranges = <0x0 0x0 0x0 0x2000>;
 
chipid@1000 {
-   compatible = "samsung,exynos850-chipid";
+   compatible = "samsung,exynos7885-chipid",
+"samsung,exynos850-chipid";
reg = <0x1000 0x24>;
};
 
@@ -264,7 +265,8 @@ pinctrl_alive: pinctrl@11cb {
reg = <0x11cb 0x1000>;
 
wakeup-interrupt-controller {
-   compatible = "samsung,exynos7-wakeup-eint";
+   compatible = "samsung,exynos7885-wakeup-eint",
+"samsung,exynos7-wakeup-eint";
interrupt-parent = <&gic>;
interrupts = ;
};
@@ -289,12 +291,14 @@ pinctrl_dispaud: pinctrl@148f {
};
 
pmu_system_controller: system-controller@11c8 {
-   compatible = "samsung,exynos7-pmu", "syscon";
+   compatible = "samsung,exynos7885-pmu",
+"samsung,exynos7-pmu", "syscon";
reg = <0x11c8 0x1>;
};
 
mmc_0: mmc@1350 {
-   compatible = "samsung,exynos7-dw-mshc-smu";
+   compatible = "samsung,exynos7885-dw-mshc-smu",
+"samsung,exynos7-dw-mshc-smu";
reg = <0x1350 0x2000>;
interrupts = ;
#address-cells = <1>;
@@ -307,7 +311,8 @@ mmc_0: mmc@1350 {
};
 
serial_0: serial@1380 {
-   compatible = "samsung,exynos5433-uart";
+   compatible = "samsung,exynos7885-uart",
+"samsung,exynos5433-uart";
reg = <0x1380 0x100>;
interrupts = ;
pinctrl-names = "default";
@@ -320,7 +325,8 @@ serial_0: serial@1380 {
};
 
serial_1: serial@1381 {
-   compatible = "samsung,exynos5433-uart";
+   compatible = "samsung,exynos7885-uart",
+"samsung,exynos5433-uart";
reg = <0x1381 0x100>;
interrupts = ;
pinctrl-names = "default";
@@ -333,7 +339,8 @@ serial_1: serial@1381 {
};
 
serial_2: serial@1382 {
-   compatible = "samsung,exynos5433-uart";
+   compatible = "samsung,exynos7885-uart",
+"samsung,exynos5433-uart";
reg = <0x1382 0x100>;
interrupts = ;
pinctrl-names = "default";
@@ -346,7 +353,8 @@ serial_2: serial@1382 {
};
 
i2c_0: i2c@1383 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos7885-i2c",
+"samsung,s3c2440-i2c";
reg = <0x1383 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -359,7 +367,8 @@ i2c_0: i2c@1383 {
};
 
i2c_1: i2c@1384 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos7885-i2c",
+"samsung,s3c2440-i2c";
reg = <0x1384 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -372,7 +381,8 @@ i2c_1: i2c@1384 {
};
 
i2c_2: i2c@1385 {
-   compatible = "samsung,s

[PATCH 16/17] arm64: dts: exynos850: add specific compatibles to several blocks

[Krzysztof Kozlowski]

Exynos850 reuses several devices from older designs, thus historically
we kept the old (block's) compatible only.  This works fine and there is
no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to Exynos850 in front of all old-SoC-like
compatibles.  This will also help reviews of new code using existing
DTS as template.  No functional impact on Linux drivers behavior.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynos850.dtsi | 34 +--
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi 
b/arch/arm64/boot/dts/exynos/exynos850.dtsi
index 53104e65b9c6..df5ea43ebcad 100644
--- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
@@ -396,7 +396,7 @@ pinctrl_aud: pinctrl@14a6 {
};
 
rtc: rtc@11a3 {
-   compatible = "samsung,s3c6410-rtc";
+   compatible = "samsung,exynos850-rtc", 
"samsung,s3c6410-rtc";
reg = <0x11a3 0x100>;
interrupts = ,
 ;
@@ -406,7 +406,8 @@ rtc: rtc@11a3 {
};
 
mmc_0: mmc@1210 {
-   compatible = "samsung,exynos7-dw-mshc-smu";
+   compatible = "samsung,exynos850-dw-mshc-smu",
+"samsung,exynos7-dw-mshc-smu";
reg = <0x1210 0x2000>;
interrupts = ;
#address-cells = <1>;
@@ -419,7 +420,7 @@ mmc_0: mmc@1210 {
};
 
i2c_0: i2c@1383 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos850-i2c", 
"samsung,s3c2440-i2c";
reg = <0x1383 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -432,7 +433,7 @@ i2c_0: i2c@1383 {
};
 
i2c_1: i2c@1384 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos850-i2c", 
"samsung,s3c2440-i2c";
reg = <0x1384 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -445,7 +446,7 @@ i2c_1: i2c@1384 {
};
 
i2c_2: i2c@1385 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos850-i2c", 
"samsung,s3c2440-i2c";
reg = <0x1385 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -458,7 +459,7 @@ i2c_2: i2c@1385 {
};
 
i2c_3: i2c@1386 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos850-i2c", 
"samsung,s3c2440-i2c";
reg = <0x1386 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -471,7 +472,7 @@ i2c_3: i2c@1386 {
};
 
i2c_4: i2c@1387 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos850-i2c", 
"samsung,s3c2440-i2c";
reg = <0x1387 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -485,7 +486,7 @@ i2c_4: i2c@1387 {
 
/* I2C_5 (also called CAM_PMIC_I2C in TRM) */
i2c_5: i2c@1388 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos850-i2c", 
"samsung,s3c2440-i2c";
reg = <0x1388 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -499,7 +500,7 @@ i2c_5: i2c@1388 {
 
/* I2C_6 (also called MOTOR_I2C in TRM) */
i2c_6: i2c@1389 {
-   compatible = "samsung,s3c2440-i2c";
+   compatible = "samsung,exynos850-i2c", 
"samsung,s3c2440-i2c";
reg = <0x1389 0x100>;
interrupts = ;
#address-cells = <1>;
@@ -640,7 +641,8 @@ usi_hsi2c_0: usi@138a00c0 {
status = "disabled";
 
hsi2c_0: i2c@138a {
-   compatible = "samsung,exynosautov9-hsi2c";
+   compatible = "samsung,exynos850-hsi2c",
+"samsung,exynosautov9-hsi2c";
reg = <0x138a 0xc0>;
interru

[PATCH 17/17] arm64: dts: exynosautov9: add specific compatibles to several blocks

[Krzysztof Kozlowski]

ExynosAutov9 reuses several devices from older designs, thus historically
we kept the old (block's) compatible only.  This works fine and there is
no bug here, however guidelines expressed in
Documentation/devicetree/bindings/writing-bindings.rst state that:
1. Compatibles should be specific.
2. We should add new compatibles in case of bugs or features.

Add compatibles specific to ExynosAutov9 in front of all old-SoC-like
compatibles.  This will also help reviews of new code using existing
DTS as template.  No functional impact on Linux drivers behavior.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm64/boot/dts/exynos/exynosautov9.dtsi | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynosautov9.dtsi 
b/arch/arm64/boot/dts/exynos/exynosautov9.dtsi
index b228cd7e351e..417aa56a81f6 100644
--- a/arch/arm64/boot/dts/exynos/exynosautov9.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynosautov9.dtsi
@@ -166,7 +166,8 @@ soc: soc@0 {
ranges = <0x0 0x0 0x0 0x2000>;
 
chipid@1000 {
-   compatible = "samsung,exynos850-chipid";
+   compatible = "samsung,exynosautov9-chipid",
+"samsung,exynos850-chipid";
reg = <0x1000 0x24>;
};
 
@@ -349,7 +350,8 @@ pinctrl_peric1: pinctrl@1083 {
};
 
pmu_system_controller: system-controller@1046 {
-   compatible = "samsung,exynos7-pmu", "syscon";
+   compatible = "samsung,exynosautov9-pmu",
+"samsung,exynos7-pmu", "syscon";
reg = <0x1046 0x1>;
 
reboot: syscon-reboot {
-- 
2.34.1

Re: [RFC PATCH v3 07/12] page-pool: device memory support

[Yunsheng Lin]

On 2023/11/8 5:56, Mina Almasry wrote:
> On Tue, Nov 7, 2023 at 12:00 AM Yunsheng Lin  wrote:
>>
>> On 2023/11/6 10:44, Mina Almasry wrote:
>>> Overload the LSB of struct page* to indicate that it's a page_pool_iov.
>>>
>>> Refactor mm calls on struct page* into helpers, and add page_pool_iov
>>> handling on those helpers. Modify callers of these mm APIs with calls to
>>> these helpers instead.
>>>
>>> In areas where struct page* is dereferenced, add a check for special
>>> handling of page_pool_iov.
>>>
>>> Signed-off-by: Mina Almasry 
>>>
>>> ---
>>>  include/net/page_pool/helpers.h | 74 -
>>>  net/core/page_pool.c| 63 
>>>  2 files changed, 118 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/include/net/page_pool/helpers.h 
>>> b/include/net/page_pool/helpers.h
>>> index b93243c2a640..08f1a2cc70d2 100644
>>> --- a/include/net/page_pool/helpers.h
>>> +++ b/include/net/page_pool/helpers.h
>>> @@ -151,6 +151,64 @@ static inline struct page_pool_iov 
>>> *page_to_page_pool_iov(struct page *page)
>>>   return NULL;
>>>  }
>>>
>>> +static inline int page_pool_page_ref_count(struct page *page)
>>> +{
>>> + if (page_is_page_pool_iov(page))
>>> + return page_pool_iov_refcount(page_to_page_pool_iov(page));
>>
>> We have added a lot of 'if' for the devmem case, it would be better to
>> make it more generic so that we can have more unified metadata handling
>> for normal page and devmem. If we add another memory type here, do we
>> need another 'if' here?
> 
> Maybe, not sure. I'm guessing new memory types will either be pages or
> iovs, so maybe no new if statements needed.
> 
>> That is part of the reason I suggested using a more unified metadata for
>> all the types of memory chunks used by page_pool.
> 
> I think your suggestion was to use struct pages for devmem. That was
> thoroughly considered and intensely argued about in the initial
> conversations regarding devmem and the initial RFC, and from the
> conclusions there it's extremely clear to me that devmem struct pages
> are categorically a no-go.

Not exactly, I was wondering if adding a more abstract structure specificly
for page pool makes any sense, and each mem type can add its own specific
fields, net stack only see and handle the common fields so that it does not
care about specific mem type, and each provider only see the and handle the
specific fields belonging to it most of the time.

Ideally something like beleow:

struct netmem {
/* common fields */
refcount_t refcount;
struct page_pool *pp;
..

union {
struct devmem{
struct dmabuf_genpool_chunk_owner *owner;
};

struct other_mem{
...
...
};
};
};

But untill we completely decouple the 'struct page' from the net stack,
the above seems undoable in the near term.
But we might be able to do something as folio is doing now, mm subsystem
is still seeing 'struct folio/page', but other subsystem like slab is using
'struct slab', and there is still some common fields shared between
'struct folio' and 'struct slab'.

As the netmem patchset, is devmem able to reuse the below 'struct netmem'
and rename it to 'struct page_pool_iov'? So that 'struct page' for normal
memory and 'struct page_pool_iov' for devmem share the common fields used
by page pool and net stack? And we might be able to reuse the 'flags',
'_pp_mapping_pad' and '_mapcount' for specific mem provider, which is enough
for the devmem only requiring a single pointer to point to it's
owner?

https://lkml.kernel.org/netdev/20230105214631.3939268-2-wi...@infradead.org/

+/**
+ * struct netmem - A memory allocation from a &struct page_pool.
+ * @flags: The same as the page flags.  Do not use directly.
+ * @pp_magic: Magic value to avoid recycling non page_pool allocated pages.
+ * @pp: The page pool this netmem was allocated from.
+ * @dma_addr: Call netmem_get_dma_addr() to read this value.
+ * @dma_addr_upper: Might need to be 64-bit on 32-bit architectures.
+ * @pp_frag_count: For frag page support, not supported in 32-bit
+ *   architectures with 64-bit DMA.
+ * @_mapcount: Do not access this member directly.
+ * @_refcount: Do not access this member directly.  Read it using
+ *   netmem_ref_count() and manipulate it with netmem_get() and netmem_put().
+ *
+ * This struct overlays struct page for now.  Do not modify without a
+ * good understanding of the issues.
+ */
+struct netmem {
+   unsigned long flags;
+   unsigned long pp_magic;
+   struct page_pool *pp;
+   /* private: no need to document this padding */
+   unsigned long _pp_mapping_pad;  /* aliases with folio->mapping */
+   /* public: */
+   unsigned long dma_addr;
+   union {
+   unsigned long dma_addr_upper;
+   atomic_long_t pp_frag_count;
+

Re: [PATCH 12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC

[Uwe Kleine-König]

Hello,

On Wed, Nov 08, 2023 at 11:43:38AM +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
> 
> Add compatibles specific to each SoC in front of all old-SoC-like
> compatibles.
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> I propose to take the patch through Samsung SoC (me). See cover letter
> for explanation.

Fine for me

Acked-by: Uwe Kleine-König 

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [RFC PATCH v3 08/12] net: support non paged skb frags

[Yunsheng Lin]

On 2023/11/8 5:19, Mina Almasry wrote:
>>
>>
> 
> My personal immediate reaction is that this may just introduce code
> churn without significant benefit. If an unsuspecting caller call
> skb_frag_page() on devmem frag and doesn't correctly handle NULL
> return, it will crash or error out anyway, and likely in some obvious
> way, so maybe the BUG_ON() isn't so useful that it's worth changing

If it will always crash or error out, then I agree that BUG_ON() is
unnecessary.

> all the call sites. But if there is consensus on adding a change like
> you propose, I have no problem adding it.

One obvious benefit I forget to mention is that, it provides a better
semantic that if a caller need to do the return checking:
1. For the old helper, the semantic is not to do the checking if the caller
   has ensure that it has passed a readable frag to skb_frag_page(), which
   avoid adding some overhead for non-devmen supported drivers.
2. For the new helper, the semantic is to do the checking and we may provide
   a compiler '__must_check' function-attribute to ensure the caller to do
   the checking.


> 

[PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Tomi Valkeinen]

These two patches are needed to make tc358767 work in the
DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector.

I have tested this with TI AM654 EVM with a tc358767 add-on card
connected to a DP monitor.

Signed-off-by: Tomi Valkeinen 
---
Changes in v2:
- Update the format negotiation patch as discussed in 
https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0...@ti.com/
- Link to v1: 
https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9...@ideasonboard.com

---
Aradhya Bhatia (1):
  drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to (e)DP

Tomi Valkeinen (1):
  drm/bridge: tc358767: Fix link properties discovery

 drivers/gpu/drm/bridge/tc358767.c | 32 
 1 file changed, 32 insertions(+)
---
base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451
change-id: 20231031-tc358767-58e3ebdf95f0

Best regards,
-- 
Tomi Valkeinen 

[PATCH v2 1/2] drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to (e)DP

[Tomi Valkeinen]

From: Aradhya Bhatia 

With new connector model, tc358767 will not create the connector, when
DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and display-controller driver will
rely on format negotiation to setup the encoder format.

Add the missing bus format negotiation hooks in the
drm_bridge_funcs to complete DRM_BRIDGE_ATTACH_NO_CONNECTOR support.

Output format, for DPI/DSI to DP, is selected to
MEDIA_BUS_FMT_RGB888_1X24 as default, keeping in mind what the older
model used to support.

Reported-by: Jan Kiszka 
Closes: 
https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8...@siemens.com/
Signed-off-by: Aradhya Bhatia 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/bridge/tc358767.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index ef2e373606ba..89a0d804270a 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1726,6 +1726,7 @@ static void tc_edp_bridge_detach(struct drm_bridge 
*bridge)
 }
 
 #define MAX_INPUT_SEL_FORMATS  1
+#define MAX_OUTPUT_SEL_FORMATS 1
 
 static u32 *
 tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
@@ -1751,6 +1752,28 @@ tc_dpi_atomic_get_input_bus_fmts(struct drm_bridge 
*bridge,
return input_fmts;
 }
 
+static u32 *
+tc_edp_atomic_get_output_bus_fmts(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ unsigned int *num_output_fmts)
+{
+   u32 *output_fmts;
+
+   *num_output_fmts = 0;
+
+   output_fmts = kcalloc(MAX_OUTPUT_SEL_FORMATS, sizeof(*output_fmts),
+ GFP_KERNEL);
+   if (!output_fmts)
+   return NULL;
+
+   output_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
+   *num_output_fmts = 1;
+
+   return output_fmts;
+}
+
 static const struct drm_bridge_funcs tc_dpi_bridge_funcs = {
.attach = tc_dpi_bridge_attach,
.mode_valid = tc_dpi_mode_valid,
@@ -1777,6 +1800,8 @@ static const struct drm_bridge_funcs tc_edp_bridge_funcs 
= {
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
.atomic_reset = drm_atomic_helper_bridge_reset,
+   .atomic_get_input_bus_fmts = drm_atomic_helper_bridge_propagate_bus_fmt,
+   .atomic_get_output_bus_fmts = tc_edp_atomic_get_output_bus_fmts,
 };
 
 static bool tc_readable_reg(struct device *dev, unsigned int reg)

-- 
2.34.1

[PATCH v2 2/2] drm/bridge: tc358767: Fix link properties discovery

[Tomi Valkeinen]

When a display controller driver uses DRM_BRIDGE_ATTACH_NO_CONNECTOR,
tc358767 will behave properly and skip the creation of the connector.

However, tc_get_display_props(), which is used to find out about the DP
monitor and link, is only called from two places: .atomic_enable() and
tc_connector_get_modes(). The latter is only used when tc358767 creates
its own connector, i.e. when DRM_BRIDGE_ATTACH_NO_CONNECTOR is _not_
set.

Thus, the driver never finds out the link properties before get_edid()
is called. With num_lanes of 0 and link_rate of 0 there are not many
valid modes...

Fix this by adding tc_get_display_props() call at the beginning of
get_edid(), so that we have up to date information before looking at the
modes.

Reported-by: Jan Kiszka 
Closes: 
https://lore.kernel.org/all/24282420-b4dd-45b3-bb1c-fc37fe4a8...@siemens.com/
Fixes: de5e6c027ae6 ("drm/bridge: tc358767: add drm_panel_bridge support")
Reviewed-by: Aradhya Bhatia 
Tested-by: Jan Kiszka 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/bridge/tc358767.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 89a0d804270a..5aafbdf423c6 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1579,6 +1579,13 @@ static struct edid *tc_get_edid(struct drm_bridge 
*bridge,
struct drm_connector *connector)
 {
struct tc_data *tc = bridge_to_tc(bridge);
+   int ret;
+
+   ret = tc_get_display_props(tc);
+   if (ret < 0) {
+   dev_err(tc->dev, "failed to read display props: %d\n", ret);
+   return 0;
+   }
 
return drm_get_edid(connector, &tc->aux.ddc);
 }

-- 
2.34.1

Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Sebastian Wick]

On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen  wrote:
>
> On Tue, 7 Nov 2023 11:58:26 -0500
> Harry Wentland  wrote:
>
> > On 2023-11-07 04:55, Pekka Paalanen wrote:
> > > On Mon, 6 Nov 2023 11:19:27 -0500
> > > Harry Wentland  wrote:
> > >
> > >> On 2023-10-20 06:36, Pekka Paalanen wrote:
> > >>> On Thu, 19 Oct 2023 10:56:40 -0400
> > >>> Harry Wentland  wrote:
> > >>>
> >  On 2023-10-10 12:13, Melissa Wen wrote:
> > > O 09/08, Harry Wentland wrote:
> > >> Signed-off-by: Harry Wentland 
> > >>>
> > >>> ...
> > >>>
> > > Also, with this new plane API in place, I understand that we will
> > > already need think on how to deal with the mixing between old drm 
> > > color
> > > properties (color encoding and color range) and these new way of 
> > > setting
> > > plane color properties. IIUC, Pekka asked a related question about it
> > > when talking about CRTC automatic RGB->YUV (?)
> > >
> > 
> >  We'll still need to confirm whether we'll want to deprecate these
> >  existing properties. If we do that we'd want a client prop. Things
> >  should still work without deprecating them, if drivers just pick up
> >  after the initial encoding and range CSC.
> > 
> >  But realistically it might be better to deprecate them and turn them
> >  into explicit colorops.
> > >>>
> > >>> The existing properties would need to be explicitly reflected in the
> > >>> new pipelines anyway, otherwise there would always be doubt at which
> > >>> point of a pipeline the old properties apply, and they might even
> > >>> need to change positions between pipelines.
> > >>>
> > >>> I think it is simply easier to just hide all old color related
> > >>> properties when userspace sets the client-cap to enable pipelines. The
> > >>> problem is to make sure to hide all old properties on all drivers that
> > >>> support the client-cap.
> > >>>
> > >>> As a pipeline must be complete (describe everything that happens to
> > >>> pixel values), it's going to be a flag day per driver.
> > >>>
> > >>> Btw. the plane FB YUV->RGB conversion needs a colorop in every pipeline
> > >>> as well. Maybe it's purely informative and non-configurable, keyed by
> > >>> FB pixel format, but still.
> > >>>
> > >>> We also need a colorop to represent sample filtering, e.g. bilinear,
> > >>> like I think Sebastian may have mentioned in the past. Everything
> > >>> before the sample filter happens "per tap" as Joshua Ashton put it, and
> > >>> everything after it happens on the sample that was computed as a
> > >>> weighted average of the filter tap inputs (texels).
> > >>>
> > >>> There could be colorops other than sample filtering that operate on
> > >>> more than one sample at a time, like blur or sharpness. There could
> > >>> even be colorops that change the image size like adding padding that
> > >>> the following colorop hardware requires, and then yet another colorop
> > >>> that clips that padding away. For an example, see
> > >>> https://lists.freedesktop.org/archives/dri-devel/2023-October/427015.html
> > >>>
> > >>> If that padding and its color can affect the pipeline results of the
> > >>> pixels near the padding (e.g. some convolution is applied with them,
> > >>> which may be the reason why padding is necessary to begin with), then
> > >>> it would be best to model it.
> > >>>
> > >>
> > >> I hear you but I'm also somewhat shying away from defining this at this 
> > >> point.
> > >
> > > Would you define them before the new UAPI is released though?
> > >
> > > I agree there is no need to have them in this patch series, but I think
> > > we'd hit the below problems if the UAPI is released without them.
> > >
> > >> There are already too many things that need to happen and I will focus 
> > >> on the
> > >> actual color blocks (LUTs, matrices) first. We'll always be able to add 
> > >> a new
> > >> (read-only) colorop type to define scaling and tap behavior at any point 
> > >> and
> > >> a client is free to ignore a color pipeline if it doesn't find any 
> > >> tap/scale
> > >> info in it.
> > >
> > > How would userspace know to look for tap/scale info, if there is no
> > > upstream definition even on paper?
> > >
> >
> > So far OSes did not care about this. Whether that's good or bad is
> > something everyone can answer for themselves.
> >
> > If you write a compositor and really need this you can just ignore
> > color pipelines that don't have this, i.e., you'll probably want
> > to wait with implementing color pipeline support until you have what
> > you need from DRM/KMS.
> >
> > This is not to say I don't want to have support for Weston. But I'm
> > wondering if we place too much importance on getting every little
> > thing figured out whereas we could be making forward progress and
> > address more aspects of a color pipeline in the future. There is a
> > reason gamescope has made a huge difference in driving the color
> > management work forward.
> >
> > > And the opp

Re: [PATCH RFC v3 12/37] drm/connector: hdmi: Create Infoframe DebugFS entries

[Jeff Hennessey]

The flux capacitor stopped fluxing...

On Fri, Nov 3, 2023, 5:06 AM Hans Verkuil  wrote:

> Hi Maxime,
>
> Thank you for posting v3, this time it runs fine on my RPi 4, thank you for
> fixing that.
>
> I'll start working on a conformity checker for this.
>
> I have a few remarks:
>
> On 31/10/2023 17:48, Maxime Ripard wrote:
> > There has been some discussions recently about the infoframes sent by
> > drivers and if they were properly generated.
> >
> > In parallel, there's been some interest in creating an infoframe-decode
> > tool similar to edid-decode.
> >
> > Both would be much easier if we were to expose the infoframes programmed
> > in the hardware. It won't be perfect since we have no guarantee that
> > it's actually what goes through the wire, but it's the best we can do.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  drivers/gpu/drm/drm_debugfs.c | 110
> ++
> >  1 file changed, 110 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_debugfs.c
> b/drivers/gpu/drm/drm_debugfs.c
> > index 2de43ff3ce0a..3c65b1d3f926 100644
> > --- a/drivers/gpu/drm/drm_debugfs.c
> > +++ b/drivers/gpu/drm/drm_debugfs.c
> > @@ -538,6 +538,114 @@ static const struct file_operations
> drm_connector_fops = {
> >   .write = connector_write
> >  };
> >
> > +struct debugfs_wrapper {
> > + struct drm_connector *connector;
> > + struct drm_connector_hdmi_infoframe *frame;
> > +};
> > +
> > +#define HDMI_MAX_INFOFRAME_SIZE  29
> > +
> > +static ssize_t
> > +infoframe_read(struct file *filp, char __user *ubuf, size_t count,
> loff_t *ppos)
> > +{
> > + const struct debugfs_wrapper *wrapper = filp->private_data;
> > + struct drm_connector *connector = wrapper->connector;
> > + struct drm_connector_hdmi_infoframe *infoframe = wrapper->frame;
> > + union hdmi_infoframe *frame = &infoframe->data;
> > + u8 buf[HDMI_MAX_INFOFRAME_SIZE];
> > + ssize_t len = 0;
> > +
> > + mutex_lock(&connector->hdmi.infoframes.lock);
> > +
> > + if (!infoframe->set)
> > + goto out;
> > +
> > + len = hdmi_infoframe_pack(frame, buf, sizeof(buf));
> > + if (len < 0)
> > + goto out;
> > +
> > + len = simple_read_from_buffer(ubuf, count, ppos, buf, len);
> > +
> > +out:
> > + mutex_unlock(&connector->hdmi.infoframes.lock);
> > + return len;
> > +}
> > +
> > +static const struct file_operations infoframe_fops = {
> > + .owner   = THIS_MODULE,
> > + .open= simple_open,
> > + .read= infoframe_read,
> > +};
> > +
> > +static int create_hdmi_infoframe_file(struct drm_connector *connector,
> > +   struct dentry *parent,
> > +   const char *filename,
> > +   struct drm_connector_hdmi_infoframe
> *frame)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + struct debugfs_wrapper *wrapper;
> > + struct dentry *file;
> > +
> > + wrapper = drmm_kzalloc(dev, sizeof(*wrapper), GFP_KERNEL);
> > + if (!wrapper)
> > + return -ENOMEM;
> > +
> > + wrapper->connector = connector;
> > + wrapper->frame = frame;
> > +
> > + file = debugfs_create_file(filename, 0400, parent, wrapper,
> &infoframe_fops);
> > + if (IS_ERR(file))
> > + return PTR_ERR(file);
> > +
> > + return 0;
> > +}
> > +
> > +#define CREATE_HDMI_INFOFRAME_FILE(c, p, i)  \
> > + create_hdmi_infoframe_file(c, p, #i, &(c)->hdmi.infoframes.i)
> > +
> > +static int create_hdmi_infoframe_files(struct drm_connector *connector,
> > +struct dentry *parent)
> > +{
> > + int ret;
> > +
> > + ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, audio);
> > + if (ret)
> > + return ret;
> > +
> > + ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, avi);
> > + if (ret)
> > + return ret;
> > +
> > + ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, drm);
>
> Hmm, I had to look into the code to figure out that 'drm' stands for
> Dynamic Range and Mastering InfoFrame. While entirely correct, it is
> also very confusing in the context of the 'drm' subsystem.
>
> I am not quite certain what the best approach is here.
>
> Internally in the drm code it is talking about 'hdr' or 'hdr metadata',
> but that's a bit confusing as well since there is also an HDR Dynamic
> Metadata Extended InfoFrame defined in CTA-861, even though support for
> that is not (yet) implemented in drm.
>
> At minimum there should be a comment in the code explaining what drm
> stands for in this context.
>
> One option to consider is renaming this file to hdr_drm, thus indicating
> that this is HDR related.
>
> > + if (ret)
> > + return ret;
> > +
> > + ret = CREATE_HDMI_INFOFRAME_FILE(connector, parent, spd);
> > + if (ret)
> > + return ret;
> > +
> > + ret = CREATE_HDMI_INFOFRAME_FILE(connector,

RE: [RFC PATCH v2 00/17] Color Pipeline API w/ VKMS

[Shankar, Uma]

> -Original Message-
> From: Harry Wentland 
> Sent: Friday, October 20, 2023 2:51 AM
> To: dri-devel@lists.freedesktop.org
> Cc: wayland-de...@lists.freedesktop.org; Harry Wentland
> ; Ville Syrjala ; Pekka
> Paalanen ; Simon Ser ;
> Melissa Wen ; Jonas Ådahl ; Sebastian
> Wick ; Shashank Sharma
> ; Alexander Goins ; Joshua
> Ashton ; Michel Dänzer ; Aleix Pol
> ; Xaver Hugl ; Victoria Brekenfeld
> ; Sima ; Shankar, Uma
> ; Naseer Ahmed ;
> Christopher Braga ; Abhinav Kumar
> ; Arthur Grillo ; Hector
> Martin ; Liviu Dudau ; Sasha
> McIntosh 
> Subject: [RFC PATCH v2 00/17] Color Pipeline API w/ VKMS
> 
> This is an early RFC set for a color pipeline API, along with a sample
> implementation in VKMS. All the key API bits are here.
> VKMS now supports two named transfer function colorops and we have an IGT
> test that confirms that sRGB EOTF, followed by its inverse gives us expected
> results within +/- 1 8 bpc codepoint value.
> 
> This patchset is grouped as follows:
>  - Patches 1-2: couple general patches/fixes
>  - Patches 3-5: introduce kunit to VKMS
>  - Patch 6: description of motivation and details behind the
> Color Pipeline API. If you're reading nothing else
> but are interested in the topic I highly recommend
> you take a look at this.
>  - Patches 7-15: Add core DRM API bits
>  - Patches 15-17: VKMS implementation
> 
> There are plenty of things that I would like to see here but haven't had a 
> chance
> to look at. These will (hopefully) be addressed in future iterations:
>  - Abandon IOCTLs and discover colorops as clients iterate the pipeline
>  - Add color_pipeline client cap and deprecate existing color encoding and
>color range properties.
>See https://lists.freedesktop.org/archives/dri-devel/2023-
> September/422643.html
>  - Add CTM colorop to VKMS
>  - Add custom LUT colorops to VKMS
>  - Add pre-blending 3DLUT with tetrahedral interpolation to VKMS
>  - How to support HW which can't bypass entire pipeline?
>  - Add ability to create colorops that don't have BYPASS
>  - Can we do a LOAD / COMMIT model for LUTs (and other properties)?
> 
> IGT tests can be found at
> https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1
> 
> IGT patches are also being sent to the igt-dev mailing list.
> 
> libdrm changes to support the new IOCTLs are at
> https://gitlab.freedesktop.org/hwentland/drm/-/merge_requests/1
> 
> If you prefer a gitlab MR for review you can find it at
> https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5
> 
> A slightly different approach for a Color Pipeline API was sent by Uma Shankar
> and can be found at https://patchwork.freedesktop.org/series/123024/
> 
> The main difference is that his approach is not introducing a new DRM core 
> object
> but instead exposes color pipelines via blob properties.
> There are pros and cons to both approaches.

Thanks Harry and all others who have actively contributed to the design and
discussions thus far.

Due to other commitments, we couldn't participate in XDC this time and also
the delay on our part. Our apologies.

We looked at the approach and are aligned to go with property-based design,
with some suggestions. Will follow in comments in respective patches.
We are also in process of trying this for Intel's hardware to identify if any 
gaps.

Regards,
Uma Shankar

> v2:
>  - Rebased on drm-misc-next
>  - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer
>  - Incorporate feedback in color_pipeline.rst doc
>  - Add support for sRGB inverse EOTF
>  - Add 2nd enumerated TF colorop to VKMS
>  - Fix LUTs and some issues with applying LUTs in VKMS
> 
> Cc: Ville Syrjala 
> Cc: Pekka Paalanen 
> Cc: Simon Ser 
> Cc: Harry Wentland 
> Cc: Melissa Wen 
> Cc: Jonas Ådahl 
> Cc: Sebastian Wick 
> Cc: Shashank Sharma 
> Cc: Alexander Goins 
> Cc: Joshua Ashton 
> Cc: Michel Dänzer 
> Cc: Aleix Pol 
> Cc: Xaver Hugl 
> Cc: Victoria Brekenfeld 
> Cc: Sima 
> Cc: Uma Shankar 
> Cc: Naseer Ahmed 
> Cc: Christopher Braga 
> Cc: Abhinav Kumar 
> Cc: Arthur Grillo 
> Cc: Hector Martin 
> Cc: Liviu Dudau 
> Cc: Sasha McIntosh 
> 
> Harry Wentland (17):
>   drm/atomic: Allow get_value for immutable properties on atomic drivers
>   drm: Don't treat 0 as -1 in drm_fixp2int_ceil
>   drm/vkms: Create separate Kconfig file for VKMS
>   drm/vkms: Add kunit tests for VKMS LUT handling
>   drm/vkms: Avoid reading beyond LUT array
>   drm/doc/rfc: Describe why prescriptive color pipeline is needed
>   drm/colorop: Introduce new drm_colorop mode object
>   drm/colorop: Add TYPE property
>   drm/color: Add 1D Curve subtype
>   drm/colorop: Add BYPASS property
>   drm/colorop: Add NEXT property
>   drm/colorop: Add atomic state print for drm_colorop
>   drm/colorop: Add new IOCTLs to retrieve drm_colorop objects
>   drm/plane: Add COLOR PIPELINE property
>   drm/colorop: Add NEXT to colorop state print
>   drm/vkms: Add enumerated 1D curve colorop
>   drm

Re: [PATCH] dt-bindings: display/msm: qcom,sm8250-mdss: add DisplayPort controller node

[Conor Dooley]

On Tue, Nov 07, 2023 at 11:36:00AM +0100, Krzysztof Kozlowski wrote:
> Document the DisplayPort controller node in MDSS binding, already used
> in DTS:
> 
>   sm8250-xiaomi-elish-boe.dtb: display-subsystem@ae0: Unevaluated 
> properties are not allowed ('displayport-controller@ae9' was unexpected)
> 
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Conor Dooley 

Cheers,
Conor.

> ---
>  .../bindings/display/msm/qcom,sm8250-mdss.yaml | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml 
> b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
> index 994975909fea..51368cda7b2f 100644
> --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8250-mdss.yaml
> @@ -52,6 +52,16 @@ patternProperties:
>compatible:
>  const: qcom,sm8250-dpu
>  
> +  "^displayport-controller@[0-9a-f]+$":
> +type: object
> +additionalProperties: true
> +
> +properties:
> +  compatible:
> +items:
> +  - const: qcom,sm8250-dp
> +  - const: qcom,sm8350-dp
> +
>"^dsi@[0-9a-f]+$":
>  type: object
>  additionalProperties: true
> -- 
> 2.34.1
> 


signature.asc
Description: PGP signature

Re: [PATCH] MAINTAINERS: Drop Emma Anholt from all M lines.

[Maíra Canal]

On 10/31/23 15:16, Emma Anholt wrote:

I am not active in the Linux kernel and don't want to see patches.

Signed-off-by: Emma Anholt 


Applied to drm-misc/drm-misc-next!

Thanks,
- Maíra


---
  MAINTAINERS | 4 
  1 file changed, 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 01fb9ee6b951..31854c48711e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5378,7 +5378,6 @@ T:git git://anongit.freedesktop.org/drm/drm-misc
  F:drivers/gpu/drm/sun4i/sun8i*
  
  DRM DRIVER FOR ARM PL111 CLCD

-M: Eric Anholt 
  S:Supported
  T:git git://anongit.freedesktop.org/drm/drm-misc
  F:drivers/gpu/drm/pl111/
@@ -5441,7 +5440,6 @@ T:git git://anongit.freedesktop.org/drm/drm-misc
  F:drivers/gpu/drm/tiny/gm12u320.c
  
  DRM DRIVER FOR HX8357D PANELS

-M: Eric Anholt 
  S:Maintained
  T:git git://anongit.freedesktop.org/drm/drm-misc
  F:Documentation/devicetree/bindings/display/himax,hx8357d.txt
@@ -5883,7 +5881,6 @@ F:Documentation/devicetree/bindings/display/ti/
  F:drivers/gpu/drm/omapdrm/
  
  DRM DRIVERS FOR V3D

-M: Eric Anholt 
  S:Supported
  T:git git://anongit.freedesktop.org/drm/drm-misc
  F:Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.txt
@@ -5891,7 +5888,6 @@ F:drivers/gpu/drm/v3d/
  F:include/uapi/drm/v3d_drm.h
  
  DRM DRIVERS FOR VC4

-M: Eric Anholt 
  S:Supported
  T:git git://github.com/anholt/linux
  T:git git://anongit.freedesktop.org/drm/drm-misc

RE: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Shankar, Uma]

> -Original Message-
> From: Harry Wentland 
> Sent: Friday, October 20, 2023 2:51 AM
> To: dri-devel@lists.freedesktop.org
> Cc: wayland-de...@lists.freedesktop.org; Harry Wentland
> ; Ville Syrjala ; Pekka
> Paalanen ; Simon Ser ;
> Melissa Wen ; Jonas Ådahl ; Sebastian
> Wick ; Shashank Sharma
> ; Alexander Goins ; Joshua
> Ashton ; Michel Dänzer ; Aleix Pol
> ; Xaver Hugl ; Victoria Brekenfeld
> ; Sima ; Shankar, Uma
> ; Naseer Ahmed ;
> Christopher Braga ; Abhinav Kumar
> ; Arthur Grillo ; Hector
> Martin ; Liviu Dudau ; Sasha
> McIntosh 
> Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color
> pipeline is needed
> 
> v2:
>  - Update colorop visualizations to match reality (Sebastian, Alex Hung)
>  - Updated wording (Pekka)
>  - Change BYPASS wording to make it non-mandatory (Sebastian)
>  - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property
>section (Pekka)
>  - Use PQ EOTF instead of its inverse in Pipeline Programming example 
> (Melissa)
>  - Add "Driver Implementer's Guide" section (Pekka)
>  - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka)
> 
> Signed-off-by: Harry Wentland 
> Cc: Ville Syrjala 
> Cc: Pekka Paalanen 
> Cc: Simon Ser 
> Cc: Harry Wentland 
> Cc: Melissa Wen 
> Cc: Jonas Ådahl 
> Cc: Sebastian Wick 
> Cc: Shashank Sharma 
> Cc: Alexander Goins 
> Cc: Joshua Ashton 
> Cc: Michel Dänzer 
> Cc: Aleix Pol 
> Cc: Xaver Hugl 
> Cc: Victoria Brekenfeld 
> Cc: Sima 
> Cc: Uma Shankar 
> Cc: Naseer Ahmed 
> Cc: Christopher Braga 
> Cc: Abhinav Kumar 
> Cc: Arthur Grillo 
> Cc: Hector Martin 
> Cc: Liviu Dudau 
> Cc: Sasha McIntosh 
> ---
>  Documentation/gpu/rfc/color_pipeline.rst | 347 +++
>  1 file changed, 347 insertions(+)
>  create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
> 
> diff --git a/Documentation/gpu/rfc/color_pipeline.rst
> b/Documentation/gpu/rfc/color_pipeline.rst
> new file mode 100644
> index ..af5f2ea29116
> --- /dev/null
> +++ b/Documentation/gpu/rfc/color_pipeline.rst
> @@ -0,0 +1,347 @@
> +
> +Linux Color Pipeline API
> +
> +
> +What problem are we solving?
> +
> +
> +We would like to support pre-, and post-blending complex color
> +transformations in display controller hardware in order to allow for
> +HW-supported HDR use-cases, as well as to provide support to
> +color-managed applications, such as video or image editors.
> +
> +It is possible to support an HDR output on HW supporting the Colorspace
> +and HDR Metadata drm_connector properties, but that requires the
> +compositor or application to render and compose the content into one
> +final buffer intended for display. Doing so is costly.
> +
> +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and
> +other operations to support color transformations. These operations are
> +often implemented in fixed-function HW and therefore much more power
> +efficient than performing similar operations via shaders or CPU.
> +
> +We would like to make use of this HW functionality to support complex
> +color transformations with no, or minimal CPU or shader load.
> +
> +
> +How are other OSes solving this problem?
> +
> +
> +The most widely supported use-cases regard HDR content, whether video
> +or gaming.
> +
> +Most OSes will specify the source content format (color gamut, encoding
> +transfer function, and other metadata, such as max and average light levels) 
> to a
> driver.
> +Drivers will then program their fixed-function HW accordingly to map
> +from a source content buffer's space to a display's space.
> +
> +When fixed-function HW is not available the compositor will assemble a
> +shader to ask the GPU to perform the transformation from the source
> +content format to the display's format.
> +
> +A compositor's mapping function and a driver's mapping function are
> +usually entirely separate concepts. On OSes where a HW vendor has no
> +insight into closed-source compositor code such a vendor will tune
> +their color management code to visually match the compositor's. On
> +other OSes, where both mapping functions are open to an implementer they will
> ensure both mappings match.
> +
> +This results in mapping algorithm lock-in, meaning that no-one alone
> +can experiment with or introduce new mapping algorithms and achieve
> +consistent results regardless of which implementation path is taken.
> +
> +Why is Linux different?
> +===
> +
> +Unlike other OSes, where there is one compositor for one or more
> +drivers, on Linux we have a many-to-many relationship. Many compositors;
> many drivers.
> +In addition each compositor vendor or community has their own view of
> +how color management should be done. This is what makes Linux so beautiful.
> +
> +This means that a HW vendor can now no longer tune their driver to one
> +compositor, as tuning it t

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Alexander Stein]

Hi Tomi,

Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen:
> These two patches are needed to make tc358767 work in the
> DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector.
> 
> I have tested this with TI AM654 EVM with a tc358767 add-on card
> connected to a DP monitor.

Just a question regarding the usage of this DSI-DP bridge.
What is the state of the DSI lanes after the DSI host has been initialized, 
but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 on DSI 
at any time for accessing the AUX channel.

Best regards,
Alexander

> Signed-off-by: Tomi Valkeinen 
> ---
> Changes in v2:
> - Update the format negotiation patch as discussed in
> https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0...@ti.com/ -
> Link to v1:
> https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard.
> com
> 
> ---
> Aradhya Bhatia (1):
>   drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to
> (e)DP
> 
> Tomi Valkeinen (1):
>   drm/bridge: tc358767: Fix link properties discovery
> 
>  drivers/gpu/drm/bridge/tc358767.c | 32 
>  1 file changed, 32 insertions(+)
> ---
> base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451
> change-id: 20231031-tc358767-58e3ebdf95f0
> 
> Best regards,


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

[Patch v2] drm/ttm: Schedule delayed_delete worker closer

[Rajneesh Bhardwaj]

Try to allocate system memory on the NUMA node the device is closest to
and try to run delayed_delete workers on a CPU of this node as well.

To optimize the memory clearing operation when a TTM BO gets freed by
the delayed_delete worker, scheduling it closer to a NUMA node where the
memory was initially allocated helps avoid the cases where the worker
gets randomly scheduled on the CPU cores that are across interconnect
boundaries such as xGMI, PCIe etc.

This change helps USWC GTT allocations on NUMA systems (dGPU) and AMD
APU platforms such as GFXIP9.4.3.

Acked-by: Felix Kuehling 
Signed-off-by: Rajneesh Bhardwaj 
---

Changes in v2:
 - Absorbed the feedback provided by Christian in the commit message and
   the comment.

 drivers/gpu/drm/ttm/ttm_bo.c | 8 +++-
 drivers/gpu/drm/ttm/ttm_device.c | 3 ++-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 5757b9415e37..6f28a77a565b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -370,7 +370,13 @@ static void ttm_bo_release(struct kref *kref)
spin_unlock(&bo->bdev->lru_lock);
 
INIT_WORK(&bo->delayed_delete, ttm_bo_delayed_delete);
-   queue_work(bdev->wq, &bo->delayed_delete);
+
+   /* Schedule the worker on the closest NUMA node. This
+* improves performance since system memory might be
+* cleared on free and that is best done on a CPU core
+* close to it.
+*/
+   queue_work_node(bdev->pool.nid, bdev->wq, 
&bo->delayed_delete);
return;
}
 
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 43e27ab77f95..72b81a2ee6c7 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -213,7 +213,8 @@ int ttm_device_init(struct ttm_device *bdev, struct 
ttm_device_funcs *funcs,
bdev->funcs = funcs;
 
ttm_sys_man_init(bdev);
-   ttm_pool_init(&bdev->pool, dev, NUMA_NO_NODE, use_dma_alloc, use_dma32);
+
+   ttm_pool_init(&bdev->pool, dev, dev_to_node(dev), use_dma_alloc, 
use_dma32);
 
bdev->vma_manager = vma_manager;
spin_lock_init(&bdev->lru_lock);
-- 
2.34.1

[PATCH 00/22] -Wmissing-prototype warning fixes

[Arnd Bergmann]

From: Arnd Bergmann 

I slightly dropped the ball on this since last sending the series in
August, but a number of warning fixes have made it into the kernel in
the meantime, both from my earlier submission and from architecture
maintainers.

I have none patches that remain from the previous submission, with
two of them reworked according to comments. The additional patches
are from more testing across architectures and configurations that
I had previously missed.

At least one patch is for a newly added warning in recent kernels.

Regarding the regressions in terms of added warnings, there are
now only five architectures left that add warnings (alpha, mips,
nios2, sh and sparc) rather than 15, so I think we can apply
the Kbuild change directly and have the architecture maintainers
take care of the warnings just like the others did already.

As before, my preference would be for the patches to make it
through the respective subsystem maintainer trees, though I
can apply the architecture specific ones to the asm-generic
tree as well.

Sorry for posting these during the merge window, I wanted to
get them out before LPC so we can have them in linux-next
as early as possible.

Arnd

Link: https://lore.kernel.org/lkml/20230810141947.1236730-1-a...@kernel.org/

Arnd Bergmann (22):
  [RESEND^2] ida: make 'ida_dump' static
  [RESEND^2] jffs2: mark __jffs2_dbg_superblock_counts() static
  [RESEND] kprobes: unify kprobes_exceptions_nofify() prototypes
  [RESEND] time: make sysfs_get_uname() function visible in header
  [RESEND] parport: gsc: mark init function static
  [RESEND] stackleak: add declarations for global functions
  [RESEND] sched: fair: move unused stub functions to header
  [v2] arch: consolidate arch_irq_work_raise prototypes
  [v2] arch: fix asm-offsets.c building with -Wmissing-prototypes
  microblaze: include linux/cpu.h for trap_init() prototype
  x86: sta2x11: include header for sta2x11_get_instance() prototype
  csky: fix arch_jump_label_transform_static override
  arch: add do_page_fault prototypes
  arch: add missing prepare_ftrace_return() prototypes
  arch: vdso: consolidate gettime prototypes
  bcachefs: mark bch2_target_to_text_sb() static
  powerpc: ps3: move udbg_shutdown_ps3gelic prototype
  powerpc: pasemi: mark pas_shutdown() static
  powerpc: powermac: mark smp_psurge_{give,take}_timebase static
  usb: fsl-mph-dr-of: mark fsl_usb2_mpc5121_init() static
  fbdev/fsl-diu-fb: mark wr_reg_wa() static
  Makefile.extrawarn: turn on missing-prototypes globally

 arch/alpha/include/asm/mmu_context.h |  2 ++
 arch/alpha/kernel/asm-offsets.c  |  2 +-
 arch/alpha/kernel/traps.c|  1 +
 arch/arc/include/asm/kprobes.h   |  3 ---
 arch/arm/include/asm/irq_work.h  |  2 --
 arch/arm/include/asm/kprobes.h   |  2 --
 arch/arm/include/asm/vdso.h  |  5 
 arch/arm/vdso/vgettimeofday.c|  1 +
 arch/arm64/include/asm/irq_work.h|  2 --
 arch/arm64/include/asm/kprobes.h |  2 --
 arch/arm64/kernel/vdso32/vgettimeofday.c |  1 +
 arch/csky/include/asm/ftrace.h   |  4 +++
 arch/csky/include/asm/irq_work.h |  2 +-
 arch/csky/include/asm/jump_label.h   |  5 
 arch/csky/include/asm/traps.h|  2 +-
 arch/csky/kernel/traps.c |  1 +
 arch/csky/kernel/vdso/vgettimeofday.c| 11 +
 arch/loongarch/kernel/asm-offsets.c  | 26 ++--
 arch/loongarch/vdso/vgettimeofday.c  |  7 +-
 arch/m68k/coldfire/vectors.c |  3 +--
 arch/m68k/coldfire/vectors.h |  3 ---
 arch/microblaze/include/asm/ftrace.h |  1 +
 arch/microblaze/kernel/traps.c   |  1 +
 arch/mips/include/asm/ftrace.h   |  4 +++
 arch/mips/include/asm/kprobes.h  |  2 --
 arch/mips/include/asm/traps.h|  3 +++
 arch/mips/vdso/vgettimeofday.c   |  1 +
 arch/nios2/include/asm/traps.h   |  2 ++
 arch/powerpc/include/asm/irq_work.h  |  1 -
 arch/powerpc/include/asm/kprobes.h   |  2 --
 arch/powerpc/include/asm/ps3.h   |  6 +
 arch/powerpc/platforms/pasemi/setup.c|  2 +-
 arch/powerpc/platforms/powermac/smp.c|  4 +--
 arch/powerpc/platforms/ps3/gelic_udbg.c  |  1 +
 arch/riscv/include/asm/irq_work.h|  2 +-
 arch/riscv/kernel/vdso/vgettimeofday.c   |  7 +-
 arch/s390/include/asm/irq_work.h |  2 --
 arch/s390/include/asm/kprobes.h  |  2 --
 arch/sh/include/asm/kprobes.h|  2 --
 arch/sh/include/asm/traps_32.h   |  3 +++
 arch/sparc/include/asm/kprobes.h |  2 --
 arch/sparc/kernel/asm-offsets.c  |  6 ++---
 arch/sparc/kernel/traps_32.c |  1 +
 arch/sparc/kernel/traps_64.c |  1 +
 arch/x86/entry/vdso/vclock_gettime.c | 10 +--

[PATCH 01/22] [RESEND^2] ida: make 'ida_dump' static

[Arnd Bergmann]

From: Arnd Bergmann 

There is no global declaration for ida_dump() and no other
callers, so make it static to avoid this warning:

lib/test_ida.c:16:6: error: no previous prototype for 'ida_dump'

Fixes: 8ab8ba38d488 ("ida: Start new test_ida module")
Signed-off-by: Arnd Bergmann 
---
 lib/test_ida.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_ida.c b/lib/test_ida.c
index b06880625961..f946c80ced8b 100644
--- a/lib/test_ida.c
+++ b/lib/test_ida.c
@@ -13,7 +13,7 @@ static unsigned int tests_run;
 static unsigned int tests_passed;
 
 #ifdef __KERNEL__
-void ida_dump(struct ida *ida) { }
+static void ida_dump(struct ida *ida) { }
 #endif
 #define IDA_BUG_ON(ida, x) do {
\
tests_run++;\
-- 
2.39.2

[PATCH 02/22] [RESEND^2] jffs2: mark __jffs2_dbg_superblock_counts() static

[Arnd Bergmann]

From: Arnd Bergmann 

This function is only called locally and does not need to be
global. Since there is no external prototype, gcc warns about
the non-static definition:

fs/jffs2/debug.c:160:6: error: no previous prototype for 
'__jffs2_dbg_superblock_counts' [-Werror=missing-prototypes]

Reviewed-by: Tudor Ambarus 
Signed-off-by: Arnd Bergmann 
---
 fs/jffs2/debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/jffs2/debug.c b/fs/jffs2/debug.c
index 9d26b1b9fc01..0925caab23c4 100644
--- a/fs/jffs2/debug.c
+++ b/fs/jffs2/debug.c
@@ -157,7 +157,7 @@ __jffs2_dbg_prewrite_paranoia_check(struct jffs2_sb_info *c,
kfree(buf);
 }
 
-void __jffs2_dbg_superblock_counts(struct jffs2_sb_info *c)
+static void __jffs2_dbg_superblock_counts(struct jffs2_sb_info *c)
 {
struct jffs2_eraseblock *jeb;
uint32_t free = 0, dirty = 0, used = 0, wasted = 0,
-- 
2.39.2

[PATCH 03/22] [RESEND] kprobes: unify kprobes_exceptions_nofify() prototypes

[Arnd Bergmann]

From: Arnd Bergmann 

Most architectures that support kprobes declare this function in their
own asm/kprobes.h header and provide an override, but some are missing
the prototype, which causes a warning for the __weak stub implementation:

kernel/kprobes.c:1865:12: error: no previous prototype for 
'kprobe_exceptions_notify' [-Werror=missing-prototypes]
 1865 | int __weak kprobe_exceptions_notify(struct notifier_block *self,

Move the prototype into linux/kprobes.h so it is visible to all
the definitions.

Acked-by: Masami Hiramatsu (Google) 
Signed-off-by: Arnd Bergmann 
---
 arch/arc/include/asm/kprobes.h | 3 ---
 arch/arm/include/asm/kprobes.h | 2 --
 arch/arm64/include/asm/kprobes.h   | 2 --
 arch/mips/include/asm/kprobes.h| 2 --
 arch/powerpc/include/asm/kprobes.h | 2 --
 arch/s390/include/asm/kprobes.h| 2 --
 arch/sh/include/asm/kprobes.h  | 2 --
 arch/sparc/include/asm/kprobes.h   | 2 --
 arch/x86/include/asm/kprobes.h | 2 --
 include/linux/kprobes.h| 4 
 10 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/arch/arc/include/asm/kprobes.h b/arch/arc/include/asm/kprobes.h
index de1566e32cb8..68e8301c0df2 100644
--- a/arch/arc/include/asm/kprobes.h
+++ b/arch/arc/include/asm/kprobes.h
@@ -32,9 +32,6 @@ struct kprobe;
 
 void arch_remove_kprobe(struct kprobe *p);
 
-int kprobe_exceptions_notify(struct notifier_block *self,
-unsigned long val, void *data);
-
 struct prev_kprobe {
struct kprobe *kp;
unsigned long status;
diff --git a/arch/arm/include/asm/kprobes.h b/arch/arm/include/asm/kprobes.h
index e26a278d301a..5b8dbf1b0be4 100644
--- a/arch/arm/include/asm/kprobes.h
+++ b/arch/arm/include/asm/kprobes.h
@@ -40,8 +40,6 @@ struct kprobe_ctlblk {
 
 void arch_remove_kprobe(struct kprobe *);
 int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
-int kprobe_exceptions_notify(struct notifier_block *self,
-unsigned long val, void *data);
 
 /* optinsn template addresses */
 extern __visible kprobe_opcode_t optprobe_template_entry[];
diff --git a/arch/arm64/include/asm/kprobes.h b/arch/arm64/include/asm/kprobes.h
index 05cd82eeca13..be7a3680dadf 100644
--- a/arch/arm64/include/asm/kprobes.h
+++ b/arch/arm64/include/asm/kprobes.h
@@ -37,8 +37,6 @@ struct kprobe_ctlblk {
 
 void arch_remove_kprobe(struct kprobe *);
 int kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr);
-int kprobe_exceptions_notify(struct notifier_block *self,
-unsigned long val, void *data);
 void __kretprobe_trampoline(void);
 void __kprobes *trampoline_probe_handler(struct pt_regs *regs);
 
diff --git a/arch/mips/include/asm/kprobes.h b/arch/mips/include/asm/kprobes.h
index 68b1e5d458cf..bc27d99c9436 100644
--- a/arch/mips/include/asm/kprobes.h
+++ b/arch/mips/include/asm/kprobes.h
@@ -71,8 +71,6 @@ struct kprobe_ctlblk {
struct prev_kprobe prev_kprobe;
 };
 
-extern int kprobe_exceptions_notify(struct notifier_block *self,
-   unsigned long val, void *data);
 
 #endif /* CONFIG_KPROBES */
 #endif /* _ASM_KPROBES_H */
diff --git a/arch/powerpc/include/asm/kprobes.h 
b/arch/powerpc/include/asm/kprobes.h
index c8e4b4fd4e33..4525a9c68260 100644
--- a/arch/powerpc/include/asm/kprobes.h
+++ b/arch/powerpc/include/asm/kprobes.h
@@ -84,8 +84,6 @@ struct arch_optimized_insn {
kprobe_opcode_t *insn;
 };
 
-extern int kprobe_exceptions_notify(struct notifier_block *self,
-   unsigned long val, void *data);
 extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
 extern int kprobe_handler(struct pt_regs *regs);
 extern int kprobe_post_handler(struct pt_regs *regs);
diff --git a/arch/s390/include/asm/kprobes.h b/arch/s390/include/asm/kprobes.h
index 21b9e5290c04..01f1682a73b7 100644
--- a/arch/s390/include/asm/kprobes.h
+++ b/arch/s390/include/asm/kprobes.h
@@ -73,8 +73,6 @@ struct kprobe_ctlblk {
 void arch_remove_kprobe(struct kprobe *p);
 
 int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
-int kprobe_exceptions_notify(struct notifier_block *self,
-   unsigned long val, void *data);
 
 #define flush_insn_slot(p) do { } while (0)
 
diff --git a/arch/sh/include/asm/kprobes.h b/arch/sh/include/asm/kprobes.h
index eeba83e0a7d2..65d4c3316a5b 100644
--- a/arch/sh/include/asm/kprobes.h
+++ b/arch/sh/include/asm/kprobes.h
@@ -46,8 +46,6 @@ struct kprobe_ctlblk {
 };
 
 extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
-extern int kprobe_exceptions_notify(struct notifier_block *self,
-   unsigned long val, void *data);
 extern int kprobe_handle_illslot(unsigned long pc);
 #else
 
diff --git a/arch/sparc/include/asm/kprobes.h b/arch/sparc/include/asm/kprobes.h
index 06c2bc767ef7..aec742cd898f 100644
--- a/arch/sparc/include/asm/kprobes.h
+++ b/arch/sparc/include/asm/kprobes.h
@@ -47,8 +47,6 @@ struct kprobe_ctlblk {
st

[PATCH 04/22] [RESEND] time: make sysfs_get_uname() function visible in header

[Arnd Bergmann]

From: Arnd Bergmann 

This function is defined globally in clocksource.c and used conditionally
in clockevent.c, which the declaration hidden when clockevent support
is disabled. This causes a harmless warning in the definition:

kernel/time/clocksource.c:1324:9: warning: no previous prototype for 
'sysfs_get_uname' [-Wmissing-prototypes]
 1324 | ssize_t sysfs_get_uname(const char *buf, char *dst, size_t cnt)

Move the declaration out of the #ifdef so it is always visible.

Signed-off-by: Arnd Bergmann 
---
 kernel/time/tick-internal.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/time/tick-internal.h b/kernel/time/tick-internal.h
index 649f2b48e8f0..481b7ab65e2c 100644
--- a/kernel/time/tick-internal.h
+++ b/kernel/time/tick-internal.h
@@ -56,7 +56,6 @@ extern int clockevents_program_event(struct 
clock_event_device *dev,
 ktime_t expires, bool force);
 extern void clockevents_handle_noop(struct clock_event_device *dev);
 extern int __clockevents_update_freq(struct clock_event_device *dev, u32 freq);
-extern ssize_t sysfs_get_uname(const char *buf, char *dst, size_t cnt);
 
 /* Broadcasting support */
 # ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
@@ -197,3 +196,5 @@ void hrtimers_resume_local(void);
 #else
 #define JIFFIES_SHIFT  8
 #endif
+
+extern ssize_t sysfs_get_uname(const char *buf, char *dst, size_t cnt);
-- 
2.39.2

[PATCH 05/22] [RESEND] parport: gsc: mark init function static

[Arnd Bergmann]

From: Arnd Bergmann 

This is only used locally, so mark it static to avoid a warning:

drivers/parport/parport_gsc.c:395:5: error: no previous prototype for 
'parport_gsc_init' [-Werror=missing-prototypes]

Acked-by: Helge Deller 
Acked-by: Sudip Mukherjee 
Signed-off-by: Arnd Bergmann 
---
 drivers/parport/parport_gsc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/parport/parport_gsc.c b/drivers/parport/parport_gsc.c
index 5e4475254bd0..c7e18382dc01 100644
--- a/drivers/parport/parport_gsc.c
+++ b/drivers/parport/parport_gsc.c
@@ -392,7 +392,7 @@ static struct parisc_driver parport_driver __refdata = {
.remove = __exit_p(parport_remove_chip),
 };
 
-int parport_gsc_init(void)
+static int parport_gsc_init(void)
 {
return register_parisc_driver(&parport_driver);
 }
-- 
2.39.2

[PATCH 06/22] [RESEND] stackleak: add declarations for global functions

[Arnd Bergmann]

From: Arnd Bergmann 

With -Wmissing-prototypes enabled, the stackleak code produces a couple of
warnings that have no declarations because they are only called from assembler:

stackleak.c:127:25: error: no previous prototype for 'stackleak_erase' 
[-Werror=missing-prototypes]
stackleak.c:139:25: error: no previous prototype for 
'stackleak_erase_on_task_stack' [-Werror=missing-prototypes]
stackleak.c:151:25: error: no previous prototype for 
'stackleak_erase_off_task_stack' [-Werror=missing-prototypes]
stackleak.c:159:49: error: no previous prototype for 'stackleak_track_stack' 
[-Werror=missing-prototypes]

Add declarations to the stackleak header to shut up the warnings.

Signed-off-by: Arnd Bergmann 
---
 include/linux/stackleak.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/stackleak.h b/include/linux/stackleak.h
index c36e7a3b45e7..3be2cb564710 100644
--- a/include/linux/stackleak.h
+++ b/include/linux/stackleak.h
@@ -14,6 +14,7 @@
 
 #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
 #include 
+#include 
 
 /*
  * The lowest address on tsk's stack which we can plausibly erase.
@@ -76,6 +77,11 @@ static inline void stackleak_task_init(struct task_struct *t)
 # endif
 }
 
+asmlinkage void noinstr stackleak_erase(void);
+asmlinkage void noinstr stackleak_erase_on_task_stack(void);
+asmlinkage void noinstr stackleak_erase_off_task_stack(void);
+void __no_caller_saved_registers noinstr stackleak_track_stack(void);
+
 #else /* !CONFIG_GCC_PLUGIN_STACKLEAK */
 static inline void stackleak_task_init(struct task_struct *t) { }
 #endif
-- 
2.39.2

[PATCH 07/22] [RESEND] sched: fair: move unused stub functions to header

[Arnd Bergmann]

From: Arnd Bergmann 

These four functions have a normal definition for CONFIG_FAIR_GROUP_SCHED,
and empty one that is only referenced when FAIR_GROUP_SCHED is disabled
but CGROUP_SCHED is still enabled. If both are turned off, the functions
are still defined but the misisng prototype causes a W=1 warning:

kernel/sched/fair.c:12544:6: error: no previous prototype for 
'free_fair_sched_group'
kernel/sched/fair.c:12546:5: error: no previous prototype for 
'alloc_fair_sched_group'
kernel/sched/fair.c:12553:6: error: no previous prototype for 
'online_fair_sched_group'
kernel/sched/fair.c:12555:6: error: no previous prototype for 
'unregister_fair_sched_group'

Move the alternatives into the header as static inline functions with
the correct combination of #ifdef checks to avoid the warning without
adding even more complexity.

[A different patch with the same description got applied by accident
 and was later reverted, but the original patch is still missing]

Fixes: 7aa55f2a5902 ("sched/fair: Move unused stub functions to header")
Signed-off-by: Arnd Bergmann 
---
A patch with the same commit log has
---
 kernel/sched/fair.c  | 13 -
 kernel/sched/sched.h | 11 +++
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2048138ce54b..82b82fa1d81b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -12927,19 +12927,6 @@ int sched_group_set_idle(struct task_group *tg, long 
idle)
return 0;
 }
 
-#else /* CONFIG_FAIR_GROUP_SCHED */
-
-void free_fair_sched_group(struct task_group *tg) { }
-
-int alloc_fair_sched_group(struct task_group *tg, struct task_group *parent)
-{
-   return 1;
-}
-
-void online_fair_sched_group(struct task_group *tg) { }
-
-void unregister_fair_sched_group(struct task_group *tg) { }
-
 #endif /* CONFIG_FAIR_GROUP_SCHED */
 
 
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 2e5a95486a42..8f5df5250b8d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -436,10 +436,21 @@ static inline int walk_tg_tree(tg_visitor down, 
tg_visitor up, void *data)
 
 extern int tg_nop(struct task_group *tg, void *data);
 
+#ifdef CONFIG_FAIR_GROUP_SCHED
 extern void free_fair_sched_group(struct task_group *tg);
 extern int alloc_fair_sched_group(struct task_group *tg, struct task_group 
*parent);
 extern void online_fair_sched_group(struct task_group *tg);
 extern void unregister_fair_sched_group(struct task_group *tg);
+#else
+static inline void free_fair_sched_group(struct task_group *tg) { }
+static inline int alloc_fair_sched_group(struct task_group *tg, struct 
task_group *parent)
+{
+   return 1;
+}
+static inline void online_fair_sched_group(struct task_group *tg) { }
+static inline void unregister_fair_sched_group(struct task_group *tg) { }
+#endif
+
 extern void init_tg_cfs_entry(struct task_group *tg, struct cfs_rq *cfs_rq,
struct sched_entity *se, int cpu,
struct sched_entity *parent);
-- 
2.39.2

[PATCH 08/22] [v2] arch: consolidate arch_irq_work_raise prototypes

[Arnd Bergmann]

From: Arnd Bergmann 

The prototype was hidden in an #ifdef on x86, which causes a warning:

kernel/irq_work.c:72:13: error: no previous prototype for 'arch_irq_work_raise' 
[-Werror=missing-prototypes]

Some architectures have a working prototype, while others don't.
Fix this by providing it in only one place that is always visible.

Acked-by: Catalin Marinas 
Acked-by: Palmer Dabbelt 
Acked-by: Guo Ren 
Reviewed-by: Alexander Gordeev 
Signed-off-by: Arnd Bergmann 
---
v2: clarify changelog text
---
 arch/arm/include/asm/irq_work.h | 2 --
 arch/arm64/include/asm/irq_work.h   | 2 --
 arch/csky/include/asm/irq_work.h| 2 +-
 arch/powerpc/include/asm/irq_work.h | 1 -
 arch/riscv/include/asm/irq_work.h   | 2 +-
 arch/s390/include/asm/irq_work.h| 2 --
 arch/x86/include/asm/irq_work.h | 1 -
 include/linux/irq_work.h| 3 +++
 8 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/arch/arm/include/asm/irq_work.h b/arch/arm/include/asm/irq_work.h
index 3149e4dc1b54..8895999834cc 100644
--- a/arch/arm/include/asm/irq_work.h
+++ b/arch/arm/include/asm/irq_work.h
@@ -9,6 +9,4 @@ static inline bool arch_irq_work_has_interrupt(void)
return is_smp();
 }
 
-extern void arch_irq_work_raise(void);
-
 #endif /* _ASM_ARM_IRQ_WORK_H */
diff --git a/arch/arm64/include/asm/irq_work.h 
b/arch/arm64/include/asm/irq_work.h
index 81bbfa3a035b..a1020285ea75 100644
--- a/arch/arm64/include/asm/irq_work.h
+++ b/arch/arm64/include/asm/irq_work.h
@@ -2,8 +2,6 @@
 #ifndef __ASM_IRQ_WORK_H
 #define __ASM_IRQ_WORK_H
 
-extern void arch_irq_work_raise(void);
-
 static inline bool arch_irq_work_has_interrupt(void)
 {
return true;
diff --git a/arch/csky/include/asm/irq_work.h b/arch/csky/include/asm/irq_work.h
index 33aaf39d6f94..d39fcc1f5395 100644
--- a/arch/csky/include/asm/irq_work.h
+++ b/arch/csky/include/asm/irq_work.h
@@ -7,5 +7,5 @@ static inline bool arch_irq_work_has_interrupt(void)
 {
return true;
 }
-extern void arch_irq_work_raise(void);
+
 #endif /* __ASM_CSKY_IRQ_WORK_H */
diff --git a/arch/powerpc/include/asm/irq_work.h 
b/arch/powerpc/include/asm/irq_work.h
index b8b0be8f1a07..c6d3078bd8c3 100644
--- a/arch/powerpc/include/asm/irq_work.h
+++ b/arch/powerpc/include/asm/irq_work.h
@@ -6,6 +6,5 @@ static inline bool arch_irq_work_has_interrupt(void)
 {
return true;
 }
-extern void arch_irq_work_raise(void);
 
 #endif /* _ASM_POWERPC_IRQ_WORK_H */
diff --git a/arch/riscv/include/asm/irq_work.h 
b/arch/riscv/include/asm/irq_work.h
index b53891964ae0..b27a4d64fc6a 100644
--- a/arch/riscv/include/asm/irq_work.h
+++ b/arch/riscv/include/asm/irq_work.h
@@ -6,5 +6,5 @@ static inline bool arch_irq_work_has_interrupt(void)
 {
return IS_ENABLED(CONFIG_SMP);
 }
-extern void arch_irq_work_raise(void);
+
 #endif /* _ASM_RISCV_IRQ_WORK_H */
diff --git a/arch/s390/include/asm/irq_work.h b/arch/s390/include/asm/irq_work.h
index 603783766d0a..f00c9f610d5a 100644
--- a/arch/s390/include/asm/irq_work.h
+++ b/arch/s390/include/asm/irq_work.h
@@ -7,6 +7,4 @@ static inline bool arch_irq_work_has_interrupt(void)
return true;
 }
 
-void arch_irq_work_raise(void);
-
 #endif /* _ASM_S390_IRQ_WORK_H */
diff --git a/arch/x86/include/asm/irq_work.h b/arch/x86/include/asm/irq_work.h
index 800ffce0db29..6b4d36c95165 100644
--- a/arch/x86/include/asm/irq_work.h
+++ b/arch/x86/include/asm/irq_work.h
@@ -9,7 +9,6 @@ static inline bool arch_irq_work_has_interrupt(void)
 {
return boot_cpu_has(X86_FEATURE_APIC);
 }
-extern void arch_irq_work_raise(void);
 #else
 static inline bool arch_irq_work_has_interrupt(void)
 {
diff --git a/include/linux/irq_work.h b/include/linux/irq_work.h
index 8cd11a223260..136f2980cba3 100644
--- a/include/linux/irq_work.h
+++ b/include/linux/irq_work.h
@@ -66,6 +66,9 @@ void irq_work_sync(struct irq_work *work);
 void irq_work_run(void);
 bool irq_work_needs_cpu(void);
 void irq_work_single(void *arg);
+
+void arch_irq_work_raise(void);
+
 #else
 static inline bool irq_work_needs_cpu(void) { return false; }
 static inline void irq_work_run(void) { }
-- 
2.39.2

[PATCH 09/22] [v2] arch: fix asm-offsets.c building with -Wmissing-prototypes

[Arnd Bergmann]

From: Arnd Bergmann 

When -Wmissing-prototypes is enabled, the some asm-offsets.c files fail
to build, even when this warning is disabled in the Makefile for normal
files:

arch/sparc/kernel/asm-offsets.c:22:5: error: no previous prototype for 
'sparc32_foo' [-Werror=missing-prototypes]
arch/sparc/kernel/asm-offsets.c:48:5: error: no previous prototype for 'foo' 
[-Werror=missing-prototypes]

Address this by making use of the same trick as x86, marking these
functions as 'static __used' to avoid the need for a prototype
by not drop them in dead-code elimination.

Suggested-by: Masahiro Yamada 
Link: 
https://lore.kernel.org/lkml/cak7lnarfemfk0du4hed19ex_g6tuc5wg0zp+l1ayvdpof4y...@mail.gmail.com/
Signed-off-by: Arnd Bergmann 
---
v2: rewrite using a different approach
---
 arch/alpha/kernel/asm-offsets.c |  2 +-
 arch/loongarch/kernel/asm-offsets.c | 26 +-
 arch/sparc/kernel/asm-offsets.c |  6 +++---
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/alpha/kernel/asm-offsets.c b/arch/alpha/kernel/asm-offsets.c
index b121294bee26..bf1eedd27cf7 100644
--- a/arch/alpha/kernel/asm-offsets.c
+++ b/arch/alpha/kernel/asm-offsets.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-void foo(void)
+static void __used foo(void)
 {
DEFINE(TI_TASK, offsetof(struct thread_info, task));
DEFINE(TI_FLAGS, offsetof(struct thread_info, flags));
diff --git a/arch/loongarch/kernel/asm-offsets.c 
b/arch/loongarch/kernel/asm-offsets.c
index 173fe514fc9e..bee9f7a3108f 100644
--- a/arch/loongarch/kernel/asm-offsets.c
+++ b/arch/loongarch/kernel/asm-offsets.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 
-void output_ptreg_defines(void)
+static void __used output_ptreg_defines(void)
 {
COMMENT("LoongArch pt_regs offsets.");
OFFSET(PT_R0, pt_regs, regs[0]);
@@ -62,7 +62,7 @@ void output_ptreg_defines(void)
BLANK();
 }
 
-void output_task_defines(void)
+static void __used output_task_defines(void)
 {
COMMENT("LoongArch task_struct offsets.");
OFFSET(TASK_STATE, task_struct, __state);
@@ -77,7 +77,7 @@ void output_task_defines(void)
BLANK();
 }
 
-void output_thread_info_defines(void)
+static void __used output_thread_info_defines(void)
 {
COMMENT("LoongArch thread_info offsets.");
OFFSET(TI_TASK, thread_info, task);
@@ -93,7 +93,7 @@ void output_thread_info_defines(void)
BLANK();
 }
 
-void output_thread_defines(void)
+static void __used output_thread_defines(void)
 {
COMMENT("LoongArch specific thread_struct offsets.");
OFFSET(THREAD_REG01, task_struct, thread.reg01);
@@ -129,7 +129,7 @@ void output_thread_defines(void)
BLANK();
 }
 
-void output_thread_fpu_defines(void)
+static void __used output_thread_fpu_defines(void)
 {
OFFSET(THREAD_FPR0, loongarch_fpu, fpr[0]);
OFFSET(THREAD_FPR1, loongarch_fpu, fpr[1]);
@@ -170,7 +170,7 @@ void output_thread_fpu_defines(void)
BLANK();
 }
 
-void output_thread_lbt_defines(void)
+static void __used output_thread_lbt_defines(void)
 {
OFFSET(THREAD_SCR0,  loongarch_lbt, scr0);
OFFSET(THREAD_SCR1,  loongarch_lbt, scr1);
@@ -180,7 +180,7 @@ void output_thread_lbt_defines(void)
BLANK();
 }
 
-void output_mm_defines(void)
+static void __used output_mm_defines(void)
 {
COMMENT("Size of struct page");
DEFINE(STRUCT_PAGE_SIZE, sizeof(struct page));
@@ -212,7 +212,7 @@ void output_mm_defines(void)
BLANK();
 }
 
-void output_sc_defines(void)
+static void __used output_sc_defines(void)
 {
COMMENT("Linux sigcontext offsets.");
OFFSET(SC_REGS, sigcontext, sc_regs);
@@ -220,7 +220,7 @@ void output_sc_defines(void)
BLANK();
 }
 
-void output_signal_defines(void)
+static void __used output_signal_defines(void)
 {
COMMENT("Linux signal numbers.");
DEFINE(_SIGHUP, SIGHUP);
@@ -258,7 +258,7 @@ void output_signal_defines(void)
 }
 
 #ifdef CONFIG_SMP
-void output_smpboot_defines(void)
+static void __used output_smpboot_defines(void)
 {
COMMENT("Linux smp cpu boot offsets.");
OFFSET(CPU_BOOT_STACK, secondary_data, stack);
@@ -268,7 +268,7 @@ void output_smpboot_defines(void)
 #endif
 
 #ifdef CONFIG_HIBERNATION
-void output_pbe_defines(void)
+static void __used output_pbe_defines(void)
 {
COMMENT("Linux struct pbe offsets.");
OFFSET(PBE_ADDRESS, pbe, address);
@@ -280,7 +280,7 @@ void output_pbe_defines(void)
 #endif
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
-void output_fgraph_ret_regs_defines(void)
+static void __used output_fgraph_ret_regs_defines(void)
 {
COMMENT("LoongArch fgraph_ret_regs offsets.");
OFFSET(FGRET_REGS_A0, fgraph_ret_regs, regs[0]);
@@ -291,7 +291,7 @@ void output_fgraph_ret_regs_defines(void)
 }
 #endif
 
-void output_kvm_defines(void)
+static void __used output_kvm_defines(void)
 {
COMMENT("KVM/LoongArch Specific offsets.");
 
diff --git a/arch/sparc/kernel/asm-offsets.c b/arch/sp

[PATCH 10/22] microblaze: include linux/cpu.h for trap_init() prototype

[Arnd Bergmann]

From: Arnd Bergmann 

Microblaze runs into a single -Wmissing-prototypes warning when that is
enabled:

arch/microblaze/kernel/traps.c:21:6: warning: no previous prototype for 
'trap_init' [-Wmissing-prototypes]

Include the right header to avoid this.

Signed-off-by: Arnd Bergmann 
---
 arch/alpha/kernel/traps.c  | 1 +
 arch/csky/include/asm/traps.h  | 2 --
 arch/csky/kernel/traps.c   | 1 +
 arch/m68k/coldfire/vectors.c   | 3 +--
 arch/m68k/coldfire/vectors.h   | 3 ---
 arch/microblaze/kernel/traps.c | 1 +
 arch/sparc/kernel/traps_32.c   | 1 +
 arch/sparc/kernel/traps_64.c   | 1 +
 arch/x86/include/asm/traps.h   | 1 -
 arch/x86/kernel/traps.c| 1 +
 10 files changed, 7 insertions(+), 8 deletions(-)
 delete mode 100644 arch/m68k/coldfire/vectors.h

diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index d9a67b370e04..7fc72aeb7398 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -9,6 +9,7 @@
  * This file initializes the trap entry points
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/csky/include/asm/traps.h b/arch/csky/include/asm/traps.h
index 732c4aaa2e26..495ce318d569 100644
--- a/arch/csky/include/asm/traps.h
+++ b/arch/csky/include/asm/traps.h
@@ -55,6 +55,4 @@ asmlinkage void trap_c(struct pt_regs *regs);
 asmlinkage void do_notify_resume(struct pt_regs *regs,
unsigned long thread_info_flags);
 
-void trap_init(void);
-
 #endif /* __ASM_CSKY_TRAPS_H */
diff --git a/arch/csky/kernel/traps.c b/arch/csky/kernel/traps.c
index 6e426fba0119..c2246b07cc9c 100644
--- a/arch/csky/kernel/traps.c
+++ b/arch/csky/kernel/traps.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/m68k/coldfire/vectors.c b/arch/m68k/coldfire/vectors.c
index c26c255b530d..4321fd89d83e 100644
--- a/arch/m68k/coldfire/vectors.c
+++ b/arch/m68k/coldfire/vectors.c
@@ -12,14 +12,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#include "vectors.h"
-
 /***/
 
 #ifdef TRAP_DBG_INTERRUPT
diff --git a/arch/m68k/coldfire/vectors.h b/arch/m68k/coldfire/vectors.h
deleted file mode 100644
index 0b01450a4353..
--- a/arch/m68k/coldfire/vectors.h
+++ /dev/null
@@ -1,3 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-
-void trap_init(void);
diff --git a/arch/microblaze/kernel/traps.c b/arch/microblaze/kernel/traps.c
index 94b6fe93147d..080aa769218d 100644
--- a/arch/microblaze/kernel/traps.c
+++ b/arch/microblaze/kernel/traps.c
@@ -8,6 +8,7 @@
  * for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/sparc/kernel/traps_32.c b/arch/sparc/kernel/traps_32.c
index 179aabfa712e..bb149f6cc34b 100644
--- a/arch/sparc/kernel/traps_32.c
+++ b/arch/sparc/kernel/traps_32.c
@@ -10,6 +10,7 @@
  * I hate traps on the sparc, grrr...
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/sparc/kernel/traps_64.c b/arch/sparc/kernel/traps_64.c
index 08ffd17d5ec3..3631899f2394 100644
--- a/arch/sparc/kernel/traps_64.c
+++ b/arch/sparc/kernel/traps_64.c
@@ -9,6 +9,7 @@
  * I like traps on v9, :
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index b1c9cea6ba88..1f1deaecd364 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -14,7 +14,6 @@
 asmlinkage __visible notrace struct pt_regs *sync_regs(struct pt_regs *eregs);
 asmlinkage __visible notrace
 struct pt_regs *fixup_bad_iret(struct pt_regs *bad_regs);
-void __init trap_init(void);
 asmlinkage __visible noinstr struct pt_regs *vc_switch_off_ist(struct pt_regs 
*eregs);
 #endif
 
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index c876f1d36a81..b0737a15c470 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.39.2

[PATCH 11/22] x86: sta2x11: include header for sta2x11_get_instance() prototype

[Arnd Bergmann]

From: Arnd Bergmann 

sta2x11_get_instance() is a global function declared in asm/sta2x11.h,
but this header is not included before the definition, causing a warning:

arch/x86/pci/sta2x11-fixup.c:95:26: error: no previous prototype for 
'sta2x11_get_instance' [-Werror=missing-prototypes]

Add the missing #include.

Fixes: 83125a3a189e ("x86, platform: Initial support for sta2x11 I/O hub")
Signed-off-by: Arnd Bergmann 
---
 arch/x86/pci/sta2x11-fixup.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/pci/sta2x11-fixup.c b/arch/x86/pci/sta2x11-fixup.c
index 7368afc03998..8c8ddc4dcc08 100644
--- a/arch/x86/pci/sta2x11-fixup.c
+++ b/arch/x86/pci/sta2x11-fixup.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define STA2X11_SWIOTLB_SIZE (4*1024*1024)
 
-- 
2.39.2

[PATCH 12/22] csky: fix arch_jump_label_transform_static override

[Arnd Bergmann]

From: Arnd Bergmann 

The arch_jump_label_transform_static() function in csky was originally meant to
override the generic __weak function, but that got changed to an #ifndef check.

This showed up as a missing-prototype warning:
arch/csky/kernel/jump_label.c:43:6: error: no previous prototype for 
'arch_jump_label_transform_static' [-Werror=missing-prototypes]

Change the method to use the new method of having a #define and a prototype
for the global function.

Fixes: 7e6b9db27de9 ("jump_label: make initial NOP patching the special case")
Fixes: 4e8bb4ba5a55 ("csky: Add jump-label implementation")
Signed-off-by: Arnd Bergmann 
---
 arch/csky/include/asm/jump_label.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/csky/include/asm/jump_label.h 
b/arch/csky/include/asm/jump_label.h
index d488ba6084bc..98a3f4b168bd 100644
--- a/arch/csky/include/asm/jump_label.h
+++ b/arch/csky/include/asm/jump_label.h
@@ -43,5 +43,10 @@ static __always_inline bool arch_static_branch_jump(struct 
static_key *key,
return true;
 }
 
+enum jump_label_type;
+void arch_jump_label_transform_static(struct jump_entry *entry,
+ enum jump_label_type type);
+#define arch_jump_label_transform_static arch_jump_label_transform_static
+
 #endif  /* __ASSEMBLY__ */
 #endif /* __ASM_CSKY_JUMP_LABEL_H */
-- 
2.39.2

[PATCH 13/22] arch: add do_page_fault prototypes

[Arnd Bergmann]

From: Arnd Bergmann 

arch/alpha/mm/fault.c:85:1: error: no previous prototype for 'do_page_fault' 
[-Werror=missing-prototypes]
arch/csky/mm/fault.c:187:17: error: no previous prototype for 'do_page_fault' 
[-Werror=missing-prototypes]
arch/mips/mm/fault.c:323:17: error: no previous prototype for 'do_page_fault' 
[-Werror=missing-prototypes]
arch/nios2/mm/fault.c:43:17: error: no previous prototype for 'do_page_fault' 
[-Werror=missing-prototypes]
arch/sh/mm/fault.c:389:27: error: no previous prototype for 'do_page_fault' 
[-Werror=missing-prototypes]

Signed-off-by: Arnd Bergmann 
---
 arch/alpha/include/asm/mmu_context.h | 2 ++
 arch/csky/include/asm/traps.h| 2 ++
 arch/mips/include/asm/traps.h| 3 +++
 arch/nios2/include/asm/traps.h   | 2 ++
 arch/sh/include/asm/traps_32.h   | 3 +++
 5 files changed, 12 insertions(+)

diff --git a/arch/alpha/include/asm/mmu_context.h 
b/arch/alpha/include/asm/mmu_context.h
index 4eea7c616992..29a3e3a1f02b 100644
--- a/arch/alpha/include/asm/mmu_context.h
+++ b/arch/alpha/include/asm/mmu_context.h
@@ -183,6 +183,8 @@ ev4_switch_mm(struct mm_struct *prev_mm, struct mm_struct 
*next_mm,
 }
 
 extern void __load_new_mm_context(struct mm_struct *);
+asmlinkage void do_page_fault(unsigned long address, unsigned long mmcsr,
+ long cause, struct pt_regs *regs);
 
 #ifdef CONFIG_SMP
 #define check_mmu_context()\
diff --git a/arch/csky/include/asm/traps.h b/arch/csky/include/asm/traps.h
index 495ce318d569..6e43165f 100644
--- a/arch/csky/include/asm/traps.h
+++ b/arch/csky/include/asm/traps.h
@@ -55,4 +55,6 @@ asmlinkage void trap_c(struct pt_regs *regs);
 asmlinkage void do_notify_resume(struct pt_regs *regs,
unsigned long thread_info_flags);
 
+asmlinkage void do_page_fault(struct pt_regs *regs);
+
 #endif /* __ASM_CSKY_TRAPS_H */
diff --git a/arch/mips/include/asm/traps.h b/arch/mips/include/asm/traps.h
index 15cde638b407..d4d9f8a8fdea 100644
--- a/arch/mips/include/asm/traps.h
+++ b/arch/mips/include/asm/traps.h
@@ -39,4 +39,7 @@ extern char except_vec_nmi[];
register_nmi_notifier(&fn##_nb);\
 })
 
+asmlinkage void do_page_fault(struct pt_regs *regs,
+   unsigned long write, unsigned long address);
+
 #endif /* _ASM_TRAPS_H */
diff --git a/arch/nios2/include/asm/traps.h b/arch/nios2/include/asm/traps.h
index 82a48473280d..afd77bef01c6 100644
--- a/arch/nios2/include/asm/traps.h
+++ b/arch/nios2/include/asm/traps.h
@@ -14,6 +14,8 @@
 
 #ifndef __ASSEMBLY__
 void _exception(int signo, struct pt_regs *regs, int code, unsigned long addr);
+void do_page_fault(struct pt_regs *regs, unsigned long cause,
+  unsigned long address);
 #endif
 
 #endif /* _ASM_NIOS2_TRAPS_H */
diff --git a/arch/sh/include/asm/traps_32.h b/arch/sh/include/asm/traps_32.h
index 8c5bbb7b6053..8f14071bea72 100644
--- a/arch/sh/include/asm/traps_32.h
+++ b/arch/sh/include/asm/traps_32.h
@@ -43,6 +43,9 @@ static inline void trigger_address_error(void)
 asmlinkage void do_address_error(struct pt_regs *regs,
 unsigned long writeaccess,
 unsigned long address);
+asmlinkage void do_page_fault(struct pt_regs *regs,
+ unsigned long error_code,
+ unsigned long address);
 asmlinkage void do_divide_error(unsigned long r4);
 asmlinkage void do_reserved_inst(void);
 asmlinkage void do_illegal_slot_inst(void);
-- 
2.39.2

[PATCH 14/22] arch: add missing prepare_ftrace_return() prototypes

[Arnd Bergmann]

From: Arnd Bergmann 

The prototype for prepare_ftrace_return() is architecture specific and
can't be in a global header. Since it's normally called from assembly,
it doesn't really need a prototype, but we get a warning if it's missing:

arch/csky/kernel/ftrace.c:147:6: error: no previous prototype for 
'prepare_ftrace_return' [-Werror=missing-prototypes]
arch/microblaze/kernel/ftrace.c:22:6: error: no previous prototype for 
'prepare_ftrace_return' [-Werror=missing-prototypes]
arch/mips/kernel/ftrace.c:305:6: error: no previous prototype for 
'prepare_ftrace_return' [-Werror=missing-prototypes]

Add the prototypes for the three architectures that don't already have
one in asm/ftrace.h.

Signed-off-by: Arnd Bergmann 
---
 arch/csky/include/asm/ftrace.h   | 4 
 arch/microblaze/include/asm/ftrace.h | 1 +
 arch/mips/include/asm/ftrace.h   | 4 
 3 files changed, 9 insertions(+)

diff --git a/arch/csky/include/asm/ftrace.h b/arch/csky/include/asm/ftrace.h
index 9b86341731b6..fd215c38ef27 100644
--- a/arch/csky/include/asm/ftrace.h
+++ b/arch/csky/include/asm/ftrace.h
@@ -26,5 +26,9 @@ static inline unsigned long ftrace_call_adjust(unsigned long 
addr)
 
 struct dyn_arch_ftrace {
 };
+
+void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr,
+  unsigned long frame_pointer);
+
 #endif /* !__ASSEMBLY__ */
 #endif /* __ASM_CSKY_FTRACE_H */
diff --git a/arch/microblaze/include/asm/ftrace.h 
b/arch/microblaze/include/asm/ftrace.h
index 6a92bed37794..4ca38b92a3a2 100644
--- a/arch/microblaze/include/asm/ftrace.h
+++ b/arch/microblaze/include/asm/ftrace.h
@@ -10,6 +10,7 @@
 #ifndef __ASSEMBLY__
 extern void _mcount(void);
 extern void ftrace_call_graph(void);
+void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr);
 #endif
 
 #ifdef CONFIG_DYNAMIC_FTRACE
diff --git a/arch/mips/include/asm/ftrace.h b/arch/mips/include/asm/ftrace.h
index db497a8167da..dc025888f6d2 100644
--- a/arch/mips/include/asm/ftrace.h
+++ b/arch/mips/include/asm/ftrace.h
@@ -85,6 +85,10 @@ struct dyn_arch_ftrace {
 };
 
 #endif /*  CONFIG_DYNAMIC_FTRACE */
+
+void prepare_ftrace_return(unsigned long *parent_ra_addr, unsigned long 
self_ra,
+  unsigned long fp);
+
 #endif /* __ASSEMBLY__ */
 #endif /* CONFIG_FUNCTION_TRACER */
 #endif /* _ASM_MIPS_FTRACE_H */
-- 
2.39.2

[PATCH 15/22] arch: vdso: consolidate gettime prototypes

[Arnd Bergmann]

From: Arnd Bergmann 

The VDSO functions are defined as globals in the kernel sources but intended
to be called from userspace, so there is no need to declare them in a kernel
side header.

Without a prototype, this now causes warnings such as

arch/mips/vdso/vgettimeofday.c:14:5: error: no previous prototype for 
'__vdso_clock_gettime' [-Werror=missing-prototypes]
arch/mips/vdso/vgettimeofday.c:28:5: error: no previous prototype for 
'__vdso_gettimeofday' [-Werror=missing-prototypes]
arch/mips/vdso/vgettimeofday.c:36:5: error: no previous prototype for 
'__vdso_clock_getres' [-Werror=missing-prototypes]
arch/mips/vdso/vgettimeofday.c:42:5: error: no previous prototype for 
'__vdso_clock_gettime64' [-Werror=missing-prototypes]
arch/sparc/vdso/vclock_gettime.c:254:1: error: no previous prototype for 
'__vdso_clock_gettime' [-Werror=missing-prototypes]
arch/sparc/vdso/vclock_gettime.c:282:1: error: no previous prototype for 
'__vdso_clock_gettime_stick' [-Werror=missing-prototypes]
arch/sparc/vdso/vclock_gettime.c:307:1: error: no previous prototype for 
'__vdso_gettimeofday' [-Werror=missing-prototypes]
arch/sparc/vdso/vclock_gettime.c:343:1: error: no previous prototype for 
'__vdso_gettimeofday_stick' [-Werror=missing-prototypes]

Most architectures have already added workarounds for these by adding
declarations somewhere, but since these are all compatible, we should
really just have one copy, with an #ifdef check for the 32-bit vs
64-bit variant and use that everywhere.

Unfortunately, the sparc version is currently incompatible since
that never added support for __vdso_clock_gettime64() in 32-bit
userland. For the moment, I'm leaving this one out, as I can't
easily test it and it requires a larger rework.

Signed-off-by: Arnd Bergmann 
---
 arch/arm/include/asm/vdso.h  |  5 -
 arch/arm/vdso/vgettimeofday.c|  1 +
 arch/arm64/kernel/vdso32/vgettimeofday.c |  1 +
 arch/csky/kernel/vdso/vgettimeofday.c| 11 +--
 arch/loongarch/vdso/vgettimeofday.c  |  7 +--
 arch/mips/vdso/vgettimeofday.c   |  1 +
 arch/riscv/kernel/vdso/vgettimeofday.c   |  7 +--
 arch/x86/entry/vdso/vclock_gettime.c | 10 +-
 arch/x86/include/asm/vdso/gettimeofday.h |  2 --
 arch/x86/um/vdso/um_vdso.c   |  1 +
 include/vdso/gettime.h   | 23 +++
 11 files changed, 31 insertions(+), 38 deletions(-)
 create mode 100644 include/vdso/gettime.h

diff --git a/arch/arm/include/asm/vdso.h b/arch/arm/include/asm/vdso.h
index 422c3afa806a..5b85889f82ee 100644
--- a/arch/arm/include/asm/vdso.h
+++ b/arch/arm/include/asm/vdso.h
@@ -24,11 +24,6 @@ static inline void arm_install_vdso(struct mm_struct *mm, 
unsigned long addr)
 
 #endif /* CONFIG_VDSO */
 
-int __vdso_clock_gettime(clockid_t clock, struct old_timespec32 *ts);
-int __vdso_clock_gettime64(clockid_t clock, struct __kernel_timespec *ts);
-int __vdso_gettimeofday(struct __kernel_old_timeval *tv, struct timezone *tz);
-int __vdso_clock_getres(clockid_t clock_id, struct old_timespec32 *res);
-
 #endif /* __ASSEMBLY__ */
 
 #endif /* __KERNEL__ */
diff --git a/arch/arm/vdso/vgettimeofday.c b/arch/arm/vdso/vgettimeofday.c
index a003beacac76..3554aa35f1ba 100644
--- a/arch/arm/vdso/vgettimeofday.c
+++ b/arch/arm/vdso/vgettimeofday.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int __vdso_clock_gettime(clockid_t clock,
 struct old_timespec32 *ts)
diff --git a/arch/arm64/kernel/vdso32/vgettimeofday.c 
b/arch/arm64/kernel/vdso32/vgettimeofday.c
index 5acff29c5991..e23c7f4ef26b 100644
--- a/arch/arm64/kernel/vdso32/vgettimeofday.c
+++ b/arch/arm64/kernel/vdso32/vgettimeofday.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2018 ARM Limited
  *
  */
+#include 
 
 int __vdso_clock_gettime(clockid_t clock,
 struct old_timespec32 *ts)
diff --git a/arch/csky/kernel/vdso/vgettimeofday.c 
b/arch/csky/kernel/vdso/vgettimeofday.c
index c4831145eed5..55af30e83752 100644
--- a/arch/csky/kernel/vdso/vgettimeofday.c
+++ b/arch/csky/kernel/vdso/vgettimeofday.c
@@ -2,36 +2,27 @@
 
 #include 
 #include 
+#include 
 
 extern
-int __vdso_clock_gettime(clockid_t clock,
-struct old_timespec32 *ts);
 int __vdso_clock_gettime(clockid_t clock,
 struct old_timespec32 *ts)
 {
return __cvdso_clock_gettime32(clock, ts);
 }
 
-int __vdso_clock_gettime64(clockid_t clock,
-  struct __kernel_timespec *ts);
 int __vdso_clock_gettime64(clockid_t clock,
   struct __kernel_timespec *ts)
 {
return __cvdso_clock_gettime(clock, ts);
 }
 
-extern
-int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
-   struct timezone *tz);
 int __vdso_gettimeofday(struct __kernel_old_timeval *tv,
struct timezone *tz)
 {
return __cvdso_gettimeofday(tv, tz);
 }
 
-extern
-int __vdso_clock_getres(clockid_t clock_id,
-  

[PATCH 16/22] bcachefs: mark bch2_target_to_text_sb() static

[Arnd Bergmann]

From: Arnd Bergmann 

bch2_target_to_text_sb() is only called in the file it is defined in,
and it has no extern prototype:

fs/bcachefs/disk_groups.c:583:6: error: no previous prototype for 
'bch2_target_to_text_sb' [-Werror=missing-prototypes]

Mark it static to avoid the warning and have the code better optimized.

Fixes: bf0d9e89de2e ("bcachefs: Split apart bch2_target_to_text(), 
bch2_target_to_text_sb()")
Signed-off-by: Arnd Bergmann 
---
 fs/bcachefs/disk_groups.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/bcachefs/disk_groups.c b/fs/bcachefs/disk_groups.c
index d613695abf9f..1f334124055b 100644
--- a/fs/bcachefs/disk_groups.c
+++ b/fs/bcachefs/disk_groups.c
@@ -580,7 +580,7 @@ void bch2_target_to_text(struct printbuf *out, struct 
bch_fs *c, unsigned v)
}
 }
 
-void bch2_target_to_text_sb(struct printbuf *out, struct bch_sb *sb, unsigned 
v)
+static void bch2_target_to_text_sb(struct printbuf *out, struct bch_sb *sb, 
unsigned v)
 {
struct target t = target_decode(v);
 
-- 
2.39.2

[PATCH 17/22] powerpc: ps3: move udbg_shutdown_ps3gelic prototype

[Arnd Bergmann]

From: Arnd Bergmann 

Allmodconfig kernels produce a missing-prototypes warning:

arch/powerpc/platforms/ps3/gelic_udbg.c:239:6: error: no previous prototype for 
'udbg_shutdown_ps3gelic' [-Werror=missing-prototypes]

Move the declaration from a local header to asm/ps3.h where it can be
seen from both the caller and the definition.

Signed-off-by: Arnd Bergmann 
---
 arch/powerpc/include/asm/ps3.h   | 6 ++
 arch/powerpc/platforms/ps3/gelic_udbg.c  | 1 +
 drivers/net/ethernet/toshiba/ps3_gelic_net.h | 6 --
 3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/ps3.h b/arch/powerpc/include/asm/ps3.h
index a5f36546a052..d13d8fdc3411 100644
--- a/arch/powerpc/include/asm/ps3.h
+++ b/arch/powerpc/include/asm/ps3.h
@@ -514,4 +514,10 @@ u64 ps3_get_spe_id(void *arg);
 
 void ps3_early_mm_init(void);
 
+#ifdef CONFIG_PPC_EARLY_DEBUG_PS3GELIC
+void udbg_shutdown_ps3gelic(void);
+#else
+static inline void udbg_shutdown_ps3gelic(void) {}
+#endif
+
 #endif
diff --git a/arch/powerpc/platforms/ps3/gelic_udbg.c 
b/arch/powerpc/platforms/ps3/gelic_udbg.c
index 6b298010fd84..a5202c18c236 100644
--- a/arch/powerpc/platforms/ps3/gelic_udbg.c
+++ b/arch/powerpc/platforms/ps3/gelic_udbg.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.h 
b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
index 0d98defb011e..0ec7412febc7 100644
--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.h
+++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
@@ -346,12 +346,6 @@ static inline void *port_priv(struct gelic_port *port)
return port->priv;
 }
 
-#ifdef CONFIG_PPC_EARLY_DEBUG_PS3GELIC
-void udbg_shutdown_ps3gelic(void);
-#else
-static inline void udbg_shutdown_ps3gelic(void) {}
-#endif
-
 int gelic_card_set_irq_mask(struct gelic_card *card, u64 mask);
 /* shared netdev ops */
 void gelic_card_up(struct gelic_card *card);
-- 
2.39.2

[PATCH 18/22] powerpc: pasemi: mark pas_shutdown() static

[Arnd Bergmann]

From: Arnd Bergmann 

Allmodconfig builds show a warning about one function that is accidentally
marked global:

arch/powerpc/platforms/pasemi/setup.c:67:6: error: no previous prototype for 
'pas_shutdown' [-Werror=missing-prototypes]

Fixes: 656fdf3ad8e0 ("powerpc/pasemi: Add Nemo board device init code.")
Signed-off-by: Arnd Bergmann 
---
 arch/powerpc/platforms/pasemi/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pasemi/setup.c 
b/arch/powerpc/platforms/pasemi/setup.c
index ef985ba2bf21..0761d98e5be3 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -64,7 +64,7 @@ static void __noreturn pas_restart(char *cmd)
 }
 
 #ifdef CONFIG_PPC_PASEMI_NEMO
-void pas_shutdown(void)
+static void pas_shutdown(void)
 {
/* Set the PLD bit that makes the SB600 think the power button is being 
pressed */
void __iomem *pld_map = ioremap(0xf500,4096);
-- 
2.39.2

[PATCH 19/22] powerpc: powermac: mark smp_psurge_{give,take}_timebase static

[Arnd Bergmann]

From: Arnd Bergmann 

These functions are only called locally and should be static like the
other corresponding functions are:

arch/powerpc/platforms/powermac/smp.c:416:13: error: no previous prototype for 
'smp_psurge_take_timebase' [-Werror=missing-prototypes]
  416 | void __init smp_psurge_take_timebase(void)
  | ^~~~
arch/powerpc/platforms/powermac/smp.c:432:13: error: no previous prototype for 
'smp_psurge_give_timebase' [-Werror=missing-prototypes]
  432 | void __init smp_psurge_give_timebase(void)
  | ^~~~

Signed-off-by: Arnd Bergmann 
---
 arch/powerpc/platforms/powermac/smp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/powermac/smp.c 
b/arch/powerpc/platforms/powermac/smp.c
index c83d1e14077e..15644be31990 100644
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c
@@ -413,7 +413,7 @@ static void __init smp_psurge_setup_cpu(int cpu_nr)
printk(KERN_ERR "Couldn't get primary IPI interrupt");
 }
 
-void __init smp_psurge_take_timebase(void)
+static void __init smp_psurge_take_timebase(void)
 {
if (psurge_type != PSURGE_DUAL)
return;
@@ -429,7 +429,7 @@ void __init smp_psurge_take_timebase(void)
set_dec(tb_ticks_per_jiffy/2);
 }
 
-void __init smp_psurge_give_timebase(void)
+static void __init smp_psurge_give_timebase(void)
 {
/* Nothing to do here */
 }
-- 
2.39.2

[PATCH 20/22] usb: fsl-mph-dr-of: mark fsl_usb2_mpc5121_init() static

[Arnd Bergmann]

From: Arnd Bergmann 

This function is only called locally and should always have been static:

drivers/usb/host/fsl-mph-dr-of.c:291:5: error: no previous prototype for 
'fsl_usb2_mpc5121_init' [-Werror=missing-prototypes]

Fixes: 230f7ede6c2f ("USB: add USB EHCI support for MPC5121 SoC")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/host/fsl-mph-dr-of.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index 8508d37a2aff..6cdc3d805c32 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -288,7 +288,7 @@ static void fsl_usb2_mph_dr_of_remove(struct 
platform_device *ofdev)
 #define PHYCTRL_LSFE   (1 << 1)/* Line State Filter Enable */
 #define PHYCTRL_PXE(1 << 0)/* PHY oscillator enable */
 
-int fsl_usb2_mpc5121_init(struct platform_device *pdev)
+static int fsl_usb2_mpc5121_init(struct platform_device *pdev)
 {
struct fsl_usb2_platform_data *pdata = dev_get_platdata(&pdev->dev);
struct clk *clk;
-- 
2.39.2

[PATCH 21/22] fbdev/fsl-diu-fb: mark wr_reg_wa() static

[Arnd Bergmann]

From: Arnd Bergmann 

wr_reg_wa() is not an appropriate name for a global function, and doesn't need
to be global anyway, so mark it static and avoid the warning:

drivers/video/fbdev/fsl-diu-fb.c:493:6: error: no previous prototype for 
'wr_reg_wa' [-Werror=missing-prototypes]

Fixes: 0d9dab39fbbe ("powerpc/5121: fsl-diu-fb: fix issue with re-enabling DIU 
area descriptor")
Signed-off-by: Arnd Bergmann 
---
 drivers/video/fbdev/fsl-diu-fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index 7fbd9f069ac2..0bced82fa494 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -490,7 +490,7 @@ static enum fsl_diu_monitor_port fsl_diu_name_to_port(const 
char *s)
  * Workaround for failed writing desc register of planes.
  * Needed with MPC5121 DIU rev 2.0 silicon.
  */
-void wr_reg_wa(u32 *reg, u32 val)
+static void wr_reg_wa(u32 *reg, u32 val)
 {
do {
out_be32(reg, val);
-- 
2.39.2

[PATCH 22/22] Makefile.extrawarn: turn on missing-prototypes globally

[Arnd Bergmann]

From: Arnd Bergmann 

Over the years we went from > 1000 of warnings to under 100 earlier
this year, and I sent patches to address all the ones that I saw with
compile testing randcom configs on arm64, arm and x86 kernels. This is a
really useful warning, as it catches real bugs when there are mismatched
prototypes. In particular with kernel control flow integrity enabled,
those are no longer allowed.

I have done extensive testing to ensure that there are no new build
errors or warnings on any configuration of x86, arm and arm64 builds.
I also made sure that at least the both the normal defconfig and an
allmodconfig build is clean for arc, csky, loongarch, m68k, microblaze,
openrisc, parisc, powerpc, riscv, s390, and xtensa, with the respective
maintainers doing most of the patches.

At this point, there are five architectures with a number of known
regressions: alpha, nios2, mips, sh and sparc. In the previous version
of this patch, I had turned off the missing prototype warnings for the 15
architectures that still had issues, but since there are only five left,
I think we can leave the rest to the maintainers (Cc'd here) as well.

Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Dinh Nguyen 
Cc: Thomas Bogendoerfer 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: "David S. Miller" 
Cc: linux-al...@vger.kernel.org
Cc: linux-m...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux...@vger.kernel.org
Link: https://lore.kernel.org/lkml/20230810141947.1236730-1-a...@kernel.org/
Reviewed-by: Kees Cook 
Acked-by: Palmer Dabbelt  # RISC-V
Signed-off-by: Arnd Bergmann 
---
 scripts/Makefile.extrawarn | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
index 2fe6f2828d37..c9725685aa76 100644
--- a/scripts/Makefile.extrawarn
+++ b/scripts/Makefile.extrawarn
@@ -17,6 +17,8 @@ KBUILD_CFLAGS += -Wno-format-security
 KBUILD_CFLAGS += -Wno-trigraphs
 KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
 KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
+KBUILD_CFLAGS += -Wmissing-declarations
+KBUILD_CFLAGS += -Wmissing-prototypes
 
 ifneq ($(CONFIG_FRAME_WARN),0)
 KBUILD_CFLAGS += -Wframe-larger-than=$(CONFIG_FRAME_WARN)
@@ -95,10 +97,8 @@ export KBUILD_EXTRA_WARN
 ifneq ($(findstring 1, $(KBUILD_EXTRA_WARN)),)
 
 KBUILD_CFLAGS += -Wextra -Wunused -Wno-unused-parameter
-KBUILD_CFLAGS += -Wmissing-declarations
 KBUILD_CFLAGS += $(call cc-option, -Wrestrict)
 KBUILD_CFLAGS += -Wmissing-format-attribute
-KBUILD_CFLAGS += -Wmissing-prototypes
 KBUILD_CFLAGS += -Wold-style-definition
 KBUILD_CFLAGS += -Wmissing-include-dirs
 KBUILD_CFLAGS += $(call cc-option, -Wunused-but-set-variable)
-- 
2.39.2

Re: [PATCH] MAINTAINERS: Add Maira to V3D maintainers

[Melissa Wen]

On 11/06, Maíra Canal wrote:
> I've been contributing to V3D with improvements, reviews, testing and
> debugging. Therefore, add myself as a co-maintainer of the V3D driver.
> 
> Signed-off-by: Maíra Canal 

Acked-by: Melissa Wen 

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f13e476ed803..3213563756cb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7108,6 +7108,7 @@ F:  drivers/gpu/drm/omapdrm/
>  DRM DRIVERS FOR V3D
>  M:   Emma Anholt 
>  M:   Melissa Wen 
> +M:   Maíra Canal 
>  S:   Supported
>  T:   git git://anongit.freedesktop.org/drm/drm-misc
>  F:   Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
> --
> 2.41.0
> 

Re: [PATCH v2 0/2] drm/bridge: tc358767: Fix DRM_BRIDGE_ATTACH_NO_CONNECTOR case

[Tomi Valkeinen]

On 08/11/2023 14:45, Alexander Stein wrote:

Hi Tomi,

Am Mittwoch, 8. November 2023, 12:27:21 CET schrieb Tomi Valkeinen:

These two patches are needed to make tc358767 work in the
DRM_BRIDGE_ATTACH_NO_CONNECTOR case, at least when using a DP connector.

I have tested this with TI AM654 EVM with a tc358767 add-on card
connected to a DP monitor.


Just a question regarding the usage of this DSI-DP bridge.
What is the state of the DSI lanes after the DSI host has been initialized,
but before calling atomic_pre_enable? AFAIK this bridge requires LP-11 on DSI
at any time for accessing the AUX channel.


Good question. I don't know, as we use it in DPI mode (DPI-DP bridge). I 
guess the DSI state is undefined, as it might well be that the DSI host 
driver's (pre-)enable is the place where the DSI is powered up and 
initialized.


So you think in DSI mode this might fail, as AUX (possibly) won't work 
when calling tc_get_edid()? We could add a check there, and skip the 
tc_get_display_props() if in DSI mode. But tc_get_edid() surely won't 
work then.


It would be good if someone with a board where tc358767 is used in DSI 
mode could test this. But, of course, it'll only be testing that 
particular DSI host behavior...


 Tomi



Best regards,
Alexander


Signed-off-by: Tomi Valkeinen 
---
Changes in v2:
- Update the format negotiation patch as discussed in
https://lore.kernel.org/all/7ddf0edb-2925-4b7c-ad07-27c030dd0...@ti.com/ -
Link to v1:
https://lore.kernel.org/r/20231031-tc358767-v1-0-392081ad9f4b@ideasonboard.
com

---
Aradhya Bhatia (1):
   drm/bridge: tc358767: Add format negotiation hooks for DPI/DSI to
(e)DP

Tomi Valkeinen (1):
   drm/bridge: tc358767: Fix link properties discovery

  drivers/gpu/drm/bridge/tc358767.c | 32 
  1 file changed, 32 insertions(+)
---
base-commit: 9d7c8c066916f231ca0ed4e4fce6c4b58ca3e451
change-id: 20231031-tc358767-58e3ebdf95f0

Best regards,

Re: [PATCH 11/17] ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoC

[Mark Brown]

On Wed, Nov 08, 2023 at 11:43:37AM +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only.  This works fine
> and there is no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:

Acked-by: Mark Brown 


signature.asc
Description: PGP signature

[PULL] drm-misc-fixes

[Maarten Lankhorst]

Hi Dave, Daniel,

drm-misc-next-fixes is empty, have a pull request for drm-misc-fixes.

Cheers,
~Maarten

drm-misc-fixes-2023-11-08:
drm-misc-fixes for v6.7-rc1:

- drm-misc-fixes from 2023-11-02 + a single qxl memory leak fix.
The following changes since commit 8f5ad367e8b884772945c6c9fb622ac94b7d3e32:

  accel/ivpu: Extend address range for MMU mmap (2023-10-19 08:01:20 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-11-08

for you to fetch changes up to 0e8b9f258baed25f1c5672613699247c76b007b5:

  drm/qxl: prevent memory leak (2023-11-06 09:37:03 +0100)


drm-misc-fixes for v6.7-rc1:

- drm-misc-fixes from 2023-11-02 + a single qxl memory leak fix.


Christian König (2):
  drm/amdgpu: ignore duplicate BOs again
  drm/amdkfd: reserve a fence slot while locking the BO

Erik Kurzinger (1):
  drm/syncobj: fix DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE

Karol Wachowski (1):
  accel/ivpu/37xx: Fix missing VPUIP interrupts

Luben Tuikov (1):
  drm/amdgpu: Remove redundant call to priority_is_valid()

Lukasz Majczak (1):
  drm/dp_mst: Fix NULL deref in get_mst_branch_device_by_guid_helper()

Maxime Ripard (1):
  drm/vc4: tests: Fix UAF in the mock helpers

Sui Jingfeng (1):
  drm/logicvc: Kconfig: select REGMAP and REGMAP_MMIO

Zongmin Zhou (1):
  drm/qxl: prevent memory leak

 drivers/accel/ivpu/ivpu_hw_37xx.c| 11 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c   |  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c  | 15 ---
 drivers/gpu/drm/display/drm_dp_mst_topology.c|  6 +++---
 drivers/gpu/drm/drm_syncobj.c|  3 ++-
 drivers/gpu/drm/logicvc/Kconfig  |  2 ++
 drivers/gpu/drm/qxl/qxl_display.c|  3 +++
 drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c|  2 +-
 drivers/gpu/drm/vc4/tests/vc4_mock_output.c  |  2 +-
 10 files changed, 28 insertions(+), 21 deletions(-)

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[Steven Price]

On 02/11/2023 14:15, AngeloGioacchino Del Regno wrote:
> The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request
> powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones:
> this means that in order to request poweroff of cores, we are supposed
> to write a bitmask of cores that should be powered off!
> This means that the panfrost_gpu_power_off() function has always been
> doing nothing.
> 
> Fix powering off the GPU by writing a bitmask of the cores to poweroff
> to the relevant PWROFF_LO registers and then check that the transition
> (from ON to OFF) has finished by polling the relevant PWRTRANS_LO
> registers.
> 
> While at it, in order to avoid code duplication, move the core mask
> logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask()
> function, used in both poweron and poweroff.
> 
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Signed-off-by: AngeloGioacchino Del Regno 
> 

Reviewed-by: Steven Price 

Thanks,

Steve

[RFC PATCH v2] drm/test: add a test suite for GEM objects backed by shmem

[Marco Pagani]

This patch introduces an initial KUnit test suite for GEM objects
backed by shmem buffers.

Suggested-by: Javier Martinez Canillas 
Signed-off-by: Marco Pagani 

v2:
- Improved description of test cases
- Cleaner error handling using KUnit actions
- Alphabetical order in Kconfig and Makefile
---
 drivers/gpu/drm/Kconfig|   9 +-
 drivers/gpu/drm/tests/Makefile |   5 +-
 drivers/gpu/drm/tests/drm_gem_shmem_test.c | 381 +
 3 files changed, 389 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/tests/drm_gem_shmem_test.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3eee8636f847..a2551c8c393a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -76,14 +76,15 @@ config DRM_KUNIT_TEST
tristate "KUnit tests for DRM" if !KUNIT_ALL_TESTS
depends on DRM && KUNIT
select PRIME_NUMBERS
+   select DRM_BUDDY
select DRM_DISPLAY_DP_HELPER
select DRM_DISPLAY_HELPER
-   select DRM_LIB_RANDOM
-   select DRM_KMS_HELPER
-   select DRM_BUDDY
+   select DRM_EXEC
select DRM_EXPORT_FOR_TESTS if m
+   select DRM_GEM_SHMEM_HELPER
+   select DRM_KMS_HELPER
select DRM_KUNIT_TEST_HELPERS
-   select DRM_EXEC
+   select DRM_LIB_RANDOM
default KUNIT_ALL_TESTS
help
  This builds unit tests for DRM. This option is not useful for
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index ba7baa622675..d6183b3d7688 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -9,15 +9,16 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_connector_test.o \
drm_damage_helper_test.o \
drm_dp_mst_helper_test.o \
+   drm_exec_test.o \
drm_format_helper_test.o \
drm_format_test.o \
drm_framebuffer_test.o \
+   drm_gem_shmem_test.o \
drm_managed_test.o \
drm_mm_test.o \
drm_modes_test.o \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
-   drm_rect_test.o \
-   drm_exec_test.o
+   drm_rect_test.o
 
 CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c 
b/drivers/gpu/drm/tests/drm_gem_shmem_test.c
new file mode 100644
index ..983380490673
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test suite for GEM objects backed by shmem buffers
+ *
+ * Copyright (C) 2023 Red Hat, Inc.
+ *
+ * Author: Marco Pagani 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TEST_SIZE  SZ_1M
+#define TEST_BYTE  0xae
+
+struct fake_dev {
+   struct drm_device drm_dev;
+   struct device *dev;
+};
+
+/*
+ * Wrappers to avoid an explicit type casting when passing action
+ * functions to kunit_add_action().
+ */
+static void kfree_wrapper(void *p)
+{
+   kfree(p);
+}
+
+static void sg_free_table_wrapper(void *sgt)
+{
+   sg_free_table(sgt);
+}
+
+static void drm_gem_shmem_free_wrapper(void *shmem)
+{
+   drm_gem_shmem_free(shmem);
+}
+
+/*
+ * Test creating a shmem GEM object backed by shmem buffer. The test
+ * case succeeds if the GEM object is successfully allocated with the
+ * shmem file node and object functions attributes set, and the size
+ * attribute is equal to the correct size.
+ */
+static void drm_gem_shmem_test_obj_create(struct kunit *test)
+{
+   struct fake_dev *fdev = test->priv;
+   struct drm_gem_shmem_object *shmem;
+
+   shmem = drm_gem_shmem_create(&fdev->drm_dev, TEST_SIZE);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem);
+   KUNIT_EXPECT_EQ(test, shmem->base.size, TEST_SIZE);
+   KUNIT_EXPECT_NOT_NULL(test, shmem->base.filp);
+   KUNIT_EXPECT_NOT_NULL(test, shmem->base.funcs);
+
+   drm_gem_shmem_free(shmem);
+}
+
+/*
+ * Test creating a shmem GEM object from a scatter/gather table exported
+ * via a DMA-BUF. The test case succeed if the GEM object is successfully
+ * created with the shmem file node attribute equal to NULL and the sgt
+ * attribute pointing to the scatter/gather table that has been imported.
+ */
+static void drm_gem_shmem_test_obj_create_private(struct kunit *test)
+{
+   struct fake_dev *fdev = test->priv;
+   struct drm_gem_shmem_object *shmem;
+   struct drm_gem_object *gem_obj;
+   struct dma_buf buf_mock;
+   struct dma_buf_attachment attach_mock;
+   struct sg_table *sgt;
+   char *buf;
+   int ret;
+
+   /* Create a mock scatter/gather table */
+   buf = kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, buf);
+
+   sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, sgt);
+
+   ret = kunit_add_action_or_reset(test, kfree_wrapper, sgt);
+   KUNIT_ASSERT_EQ(test, r

Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Joshua Ashton]

On 11/8/23 12:18, Shankar, Uma wrote:




-Original Message-
From: Harry Wentland 
Sent: Friday, October 20, 2023 2:51 AM
To: dri-devel@lists.freedesktop.org
Cc: wayland-de...@lists.freedesktop.org; Harry Wentland
; Ville Syrjala ; Pekka
Paalanen ; Simon Ser ;
Melissa Wen ; Jonas Ådahl ; Sebastian
Wick ; Shashank Sharma
; Alexander Goins ; Joshua
Ashton ; Michel Dänzer ; Aleix Pol
; Xaver Hugl ; Victoria Brekenfeld
; Sima ; Shankar, Uma
; Naseer Ahmed ;
Christopher Braga ; Abhinav Kumar
; Arthur Grillo ; Hector
Martin ; Liviu Dudau ; Sasha
McIntosh 
Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color
pipeline is needed

v2:
  - Update colorop visualizations to match reality (Sebastian, Alex Hung)
  - Updated wording (Pekka)
  - Change BYPASS wording to make it non-mandatory (Sebastian)
  - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property
section (Pekka)
  - Use PQ EOTF instead of its inverse in Pipeline Programming example (Melissa)
  - Add "Driver Implementer's Guide" section (Pekka)
  - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka)

Signed-off-by: Harry Wentland 
Cc: Ville Syrjala 
Cc: Pekka Paalanen 
Cc: Simon Ser 
Cc: Harry Wentland 
Cc: Melissa Wen 
Cc: Jonas Ådahl 
Cc: Sebastian Wick 
Cc: Shashank Sharma 
Cc: Alexander Goins 
Cc: Joshua Ashton 
Cc: Michel Dänzer 
Cc: Aleix Pol 
Cc: Xaver Hugl 
Cc: Victoria Brekenfeld 
Cc: Sima 
Cc: Uma Shankar 
Cc: Naseer Ahmed 
Cc: Christopher Braga 
Cc: Abhinav Kumar 
Cc: Arthur Grillo 
Cc: Hector Martin 
Cc: Liviu Dudau 
Cc: Sasha McIntosh 
---
  Documentation/gpu/rfc/color_pipeline.rst | 347 +++
  1 file changed, 347 insertions(+)
  create mode 100644 Documentation/gpu/rfc/color_pipeline.rst

diff --git a/Documentation/gpu/rfc/color_pipeline.rst
b/Documentation/gpu/rfc/color_pipeline.rst
new file mode 100644
index ..af5f2ea29116
--- /dev/null
+++ b/Documentation/gpu/rfc/color_pipeline.rst
@@ -0,0 +1,347 @@
+
+Linux Color Pipeline API
+
+
+What problem are we solving?
+
+
+We would like to support pre-, and post-blending complex color
+transformations in display controller hardware in order to allow for
+HW-supported HDR use-cases, as well as to provide support to
+color-managed applications, such as video or image editors.
+
+It is possible to support an HDR output on HW supporting the Colorspace
+and HDR Metadata drm_connector properties, but that requires the
+compositor or application to render and compose the content into one
+final buffer intended for display. Doing so is costly.
+
+Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and
+other operations to support color transformations. These operations are
+often implemented in fixed-function HW and therefore much more power
+efficient than performing similar operations via shaders or CPU.
+
+We would like to make use of this HW functionality to support complex
+color transformations with no, or minimal CPU or shader load.
+
+
+How are other OSes solving this problem?
+
+
+The most widely supported use-cases regard HDR content, whether video
+or gaming.
+
+Most OSes will specify the source content format (color gamut, encoding
+transfer function, and other metadata, such as max and average light levels) 
to a
driver.
+Drivers will then program their fixed-function HW accordingly to map
+from a source content buffer's space to a display's space.
+
+When fixed-function HW is not available the compositor will assemble a
+shader to ask the GPU to perform the transformation from the source
+content format to the display's format.
+
+A compositor's mapping function and a driver's mapping function are
+usually entirely separate concepts. On OSes where a HW vendor has no
+insight into closed-source compositor code such a vendor will tune
+their color management code to visually match the compositor's. On
+other OSes, where both mapping functions are open to an implementer they will
ensure both mappings match.
+
+This results in mapping algorithm lock-in, meaning that no-one alone
+can experiment with or introduce new mapping algorithms and achieve
+consistent results regardless of which implementation path is taken.
+
+Why is Linux different?
+===
+
+Unlike other OSes, where there is one compositor for one or more
+drivers, on Linux we have a many-to-many relationship. Many compositors;
many drivers.
+In addition each compositor vendor or community has their own view of
+how color management should be done. This is what makes Linux so beautiful.
+
+This means that a HW vendor can now no longer tune their driver to one
+compositor, as tuning it to one could make it look fairly different
+from another compositor's color mapping.
+
+We need a better solution.
+
+
+Descriptive API
+===
+
+An API that describes the source and destination colorspa

[PATCH v6 0/8] Improve test coverage of TTM

[Karolina Stolarek]

Add tests for building blocks of the TTM subsystem, such as ttm_resource,
ttm_resource_manager, ttm_tt and ttm_buffer_object. This series covers
basic functions such as initialization, allocation and clean-up of each
struct. Testing of ttm_buffer_object also includes locking and unlocking
the object for validation, with special scenarios such as an interrupted
wait or deadlock.

Some of the test cases check the bulk move mechanism and how it interacts
with pinned buffers. This is to be seen if we want to add dedicated testing
for bulk move or not. The resource allocation subtests use ttm_sys_manager
for now. Resources that don't use system memory will be indirectly tested
via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock
resource manager.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/ttm/tests

To build a kernel with TTM KUnit tests, first enable CONFIG_KUNIT, and
then CONFIG_DRM_TTM_KUNIT_TEST.

Many thanks,
Karolina

v6:
  - Include tests for ttm_bo_init_reserved() and ttm_bo_validate(), with
a mock resource manager (patches 6-8; no eviction testing)
  - Add ttm_test_devices_all_init() helper to also init ttm_device instance
  - Remove fpfn and lpfn from ttm_place_kunit_init() helper -- these fields
are neither used nor tested

v5:
  - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
  - First unreserve the object before calling ww_acquire_fini() in
ttm_bo_reserve_double_resv subtest
  - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to suggestions
how to fix it in a different way)
  - Use a genuine GEM object in ttm_buffer_object instead of an empty one

v3:
  - Instead of modifying the main TTM Makefile, use
EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are tested but
not widely exported. Thanks to this change, TTM tests can be built
as modules, even when non-exported functions are used
  - Change the description of a patch that fixes ttm_pool_pre_populated()

v2:
  - Remove Makefile for KUnit tests and move the definitions to the
TTM's one
  - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM module
are built as one. This allows building the tests as a module, even
if it uses functions that are not exported
  - Fix ttm_pool_pre_populated(); a wrong flag was passed to
ttm_tt_kunit_init() function

Karolina Stolarek (8):
  drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
  drm/ttm/tests: Add tests for ttm_tt
  drm/ttm/tests: Add tests for ttm_bo functions
  drm/ttm/tests: Fix argument in ttm_tt_kunit_init()
  drm/ttm/tests: Use an init function from the helpers lib
  drm/ttm/tests: Test simple BO creation and validation
  drm/ttm/tests: Add tests with mock resource managers
  drm/ttm/tests: Add test cases dependent on fence signaling

 drivers/gpu/drm/Kconfig   |   1 +
 drivers/gpu/drm/ttm/tests/.kunitconfig|   1 +
 drivers/gpu/drm/ttm/tests/Makefile|   5 +
 drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 ++
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 792 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 110 ++-
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   8 +
 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c  | 194 +
 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h  |  30 +
 drivers/gpu/drm/ttm/tests/ttm_pool_test.c |   3 +-
 drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 
 drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 282 +++
 drivers/gpu/drm/ttm/ttm_resource.c|   3 +
 drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
 14 files changed, 2383 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c

-- 
2.25.1

[PATCH v6 1/8] drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man

[Karolina Stolarek]

Test initialization of ttm_resource using different memory domains.
Add tests for a system memory manager and functions that can be
tested without a fully-featured resource manager. Update
ttm_bo_kunit_init() to initialize BO's kref and a genuine GEM drm
object. Export ttm_resource_alloc for test purposes only.

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 
---
 drivers/gpu/drm/ttm/tests/Makefile|   1 +
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  23 +-
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   4 +
 drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
 drivers/gpu/drm/ttm/ttm_resource.c|   3 +
 5 files changed, 365 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index ec87c4fc1ad5..c92fe2052ef6 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -3,4 +3,5 @@
 obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
 ttm_device_test.o \
 ttm_pool_test.o \
+ttm_resource_test.o \
 ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 81661d8827aa..dea7e6413d53 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -29,19 +29,40 @@ struct ttm_buffer_object *ttm_bo_kunit_init(struct kunit 
*test,
struct ttm_test_devices *devs,
size_t size)
 {
-   struct drm_gem_object gem_obj = { .size = size };
+   struct drm_gem_object gem_obj = { };
struct ttm_buffer_object *bo;
+   int err;
 
bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
KUNIT_ASSERT_NOT_NULL(test, bo);
 
bo->base = gem_obj;
+   err = drm_gem_object_init(devs->drm, &bo->base, size);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
bo->bdev = devs->ttm_dev;
+   kref_init(&bo->kref);
 
return bo;
 }
 EXPORT_SYMBOL_GPL(ttm_bo_kunit_init);
 
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+  uint32_t mem_type, uint32_t flags,
+  size_t size)
+{
+   struct ttm_place *place;
+
+   place = kunit_kzalloc(test, sizeof(*place), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, place);
+
+   place->mem_type = mem_type;
+   place->flags = flags;
+
+   return place;
+}
+EXPORT_SYMBOL_GPL(ttm_place_kunit_init);
+
 struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test)
 {
struct ttm_test_devices *devs;
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index e261e3660d0b..f38140f93c05 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -28,6 +29,9 @@ int ttm_device_kunit_init(struct ttm_test_devices *priv,
 struct ttm_buffer_object *ttm_bo_kunit_init(struct kunit *test,
struct ttm_test_devices *devs,
size_t size);
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+  uint32_t mem_type, uint32_t flags,
+  size_t size);
 
 struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test);
 struct ttm_test_devices *ttm_test_devices_all(struct kunit *test);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
new file mode 100644
index ..851cdc43dc37
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+#define RES_SIZE   SZ_4K
+#define TTM_PRIV_DUMMY_REG (TTM_NUM_MEM_TYPES - 1)
+
+struct ttm_resource_test_case {
+   const char *description;
+   uint32_t mem_type;
+   uint32_t flags;
+};
+
+struct ttm_resource_test_priv {
+   struct ttm_test_devices *devs;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+};
+
+static const struct ttm_resource_manager_func ttm_resource_manager_mock_funcs 
= { };
+
+static int ttm_resource_test_init(struct kunit *test)
+{
+   struct ttm_resource_test_priv *priv;
+
+   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, priv);
+
+   priv->devs = ttm_test_devices_all(test);
+   KUNIT_ASSERT_NOT_NULL(test, priv->devs);
+
+   test->priv = priv;
+
+   return 0;
+}
+
+static void ttm_resource_test_fini(struct kunit *test)
+{
+   struct ttm_resource_test_priv *pri

[PATCH v6 3/8] drm/ttm/tests: Add tests for ttm_bo functions

[Karolina Stolarek]

Test reservation and release of TTM buffer objects. Add tests to check
pin and unpin operations.

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 
---
 drivers/gpu/drm/ttm/tests/Makefile|   1 +
 drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |   6 +
 3 files changed, 626 insertions(+)
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index f570530bbb60..468535f7eed2 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
 ttm_pool_test.o \
 ttm_resource_test.o \
 ttm_tt_test.o \
+ttm_bo_test.o \
 ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
new file mode 100644
index ..f0c829fdb67b
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
@@ -0,0 +1,619 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+#define BO_SIZESZ_8K
+
+struct ttm_bo_test_case {
+   const char *description;
+   bool interruptible;
+   bool no_wait;
+};
+
+static const struct ttm_bo_test_case ttm_bo_reserved_cases[] = {
+   {
+   .description = "Cannot be interrupted and sleeps",
+   .interruptible = false,
+   .no_wait = false,
+   },
+   {
+   .description = "Cannot be interrupted, locks straight away",
+   .interruptible = false,
+   .no_wait = true,
+   },
+   {
+   .description = "Can be interrupted, sleeps",
+   .interruptible = true,
+   .no_wait = false,
+   },
+};
+
+static void ttm_bo_init_case_desc(const struct ttm_bo_test_case *t,
+ char *desc)
+{
+   strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+KUNIT_ARRAY_PARAM(ttm_bo_reserve, ttm_bo_reserved_cases, 
ttm_bo_init_case_desc);
+
+static void ttm_bo_reserve_optimistic_no_ticket(struct kunit *test)
+{
+   const struct ttm_bo_test_case *params = test->param_value;
+   struct ttm_buffer_object *bo;
+   int err;
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   err = ttm_bo_reserve(bo, params->interruptible, params->no_wait, NULL);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   dma_resv_unlock(bo->base.resv);
+}
+
+static void ttm_bo_reserve_locked_no_sleep(struct kunit *test)
+{
+   struct ttm_buffer_object *bo;
+   bool interruptible = false;
+   bool no_wait = true;
+   int err;
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   /* Let's lock it beforehand */
+   dma_resv_lock(bo->base.resv, NULL);
+
+   err = ttm_bo_reserve(bo, interruptible, no_wait, NULL);
+   dma_resv_unlock(bo->base.resv);
+
+   KUNIT_ASSERT_EQ(test, err, -EBUSY);
+}
+
+static void ttm_bo_reserve_no_wait_ticket(struct kunit *test)
+{
+   struct ttm_buffer_object *bo;
+   struct ww_acquire_ctx ctx;
+   bool interruptible = false;
+   bool no_wait = true;
+   int err;
+
+   ww_acquire_init(&ctx, &reservation_ww_class);
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   err = ttm_bo_reserve(bo, interruptible, no_wait, &ctx);
+   KUNIT_ASSERT_EQ(test, err, -EBUSY);
+
+   ww_acquire_fini(&ctx);
+}
+
+static void ttm_bo_reserve_double_resv(struct kunit *test)
+{
+   struct ttm_buffer_object *bo;
+   struct ww_acquire_ctx ctx;
+   bool interruptible = false;
+   bool no_wait = false;
+   int err;
+
+   ww_acquire_init(&ctx, &reservation_ww_class);
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   err = ttm_bo_reserve(bo, interruptible, no_wait, &ctx);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   err = ttm_bo_reserve(bo, interruptible, no_wait, &ctx);
+
+   dma_resv_unlock(bo->base.resv);
+   ww_acquire_fini(&ctx);
+
+   KUNIT_ASSERT_EQ(test, err, -EALREADY);
+}
+
+/*
+ * A test case heavily inspired by ww_test_edeadlk_normal(). Checks
+ * if -EDEADLK is properly propagated by ttm_bo_reserve()
+ */
+static void ttm_bo_reserve_deadlock(struct kunit *test)
+{
+   struct ttm_buffer_object *bo1, *bo2;
+   struct ww_acquire_ctx ctx1, ctx2;
+   bool interruptible = false;
+   bool no_wait = false;
+   int err;
+
+   bo1 = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+   bo2 = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   ww_acquire_init(&ctx1, &reservation_ww_class);
+   mutex_lock(&bo2->base.resv->lock.base);
+
+   /* The deadlock will be caught by WW mutex, don't warn abou

[PATCH v6 5/8] drm/ttm/tests: Use an init function from the helpers lib

[Karolina Stolarek]

Add a new helper function that also initializes the device. Use it in
ttm_tt test suite and delete the local definition.

Signed-off-by: Karolina Stolarek 
---
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 14 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |  1 +
 drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 15 +--
 3 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 10c5e7f54ff3..5526669c1f19 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -151,6 +151,20 @@ int ttm_test_devices_init(struct kunit *test)
 }
 EXPORT_SYMBOL_GPL(ttm_test_devices_init);
 
+int ttm_test_devices_all_init(struct kunit *test)
+{
+   struct ttm_test_devices *priv;
+
+   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, priv);
+
+   priv = ttm_test_devices_all(test);
+   test->priv = priv;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(ttm_test_devices_all_init);
+
 void ttm_test_devices_fini(struct kunit *test)
 {
ttm_test_devices_put(test, test->priv);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index f38140f93c05..1455a5ac2462 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -40,6 +40,7 @@ void ttm_test_devices_put(struct kunit *test, struct 
ttm_test_devices *devs);
 
 /* Generic init/fini for tests that only need DRM/TTM devices */
 int ttm_test_devices_init(struct kunit *test);
+int ttm_test_devices_all_init(struct kunit *test);
 void ttm_test_devices_fini(struct kunit *test);
 
 #endif // TTM_KUNIT_HELPERS_H
diff --git a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
index 4f5fc4d460b4..98c3deef94e3 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
@@ -15,19 +15,6 @@ struct ttm_tt_test_case {
uint32_t extra_pages_num;
 };
 
-static int ttm_tt_test_init(struct kunit *test)
-{
-   struct ttm_test_devices *priv;
-
-   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
-   KUNIT_ASSERT_NOT_NULL(test, priv);
-
-   priv = ttm_test_devices_all(test);
-   test->priv = priv;
-
-   return 0;
-}
-
 static const struct ttm_tt_test_case ttm_tt_init_basic_cases[] = {
{
.description = "Page-aligned size",
@@ -285,7 +272,7 @@ static struct kunit_case ttm_tt_test_cases[] = {
 
 static struct kunit_suite ttm_tt_test_suite = {
.name = "ttm_tt",
-   .init = ttm_tt_test_init,
+   .init = ttm_test_devices_all_init,
.exit = ttm_test_devices_fini,
.test_cases = ttm_tt_test_cases,
 };
-- 
2.25.1

[PATCH v6 2/8] drm/ttm/tests: Add tests for ttm_tt

[Karolina Stolarek]

Test initialization, creation and destruction of ttm_tt instances.
Export ttm_tt_destroy and ttm_tt_create symbols for testing purposes.

Signed-off-by: Karolina Stolarek 
Reviewed-by: Christian König 
Tested-by: Amaranath Somalapuram 
---
 drivers/gpu/drm/ttm/tests/Makefile|   1 +
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  20 ++
 drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 295 ++
 drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
 4 files changed, 319 insertions(+)
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index c92fe2052ef6..f570530bbb60 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -4,4 +4,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
 ttm_device_test.o \
 ttm_pool_test.o \
 ttm_resource_test.o \
+ttm_tt_test.o \
 ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index dea7e6413d53..2bfc636a00b6 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -2,9 +2,29 @@
 /*
  * Copyright © 2023 Intel Corporation
  */
+#include 
+
 #include "ttm_kunit_helpers.h"
 
+static struct ttm_tt *ttm_tt_simple_create(struct ttm_buffer_object *bo,
+  uint32_t page_flags)
+{
+   struct ttm_tt *tt;
+
+   tt = kzalloc(sizeof(*tt), GFP_KERNEL);
+   ttm_tt_init(tt, bo, page_flags, ttm_cached, 0);
+
+   return tt;
+}
+
+static void ttm_tt_simple_destroy(struct ttm_device *bdev, struct ttm_tt *ttm)
+{
+   kfree(ttm);
+}
+
 struct ttm_device_funcs ttm_dev_funcs = {
+   .ttm_tt_create = ttm_tt_simple_create,
+   .ttm_tt_destroy = ttm_tt_simple_destroy,
 };
 EXPORT_SYMBOL_GPL(ttm_dev_funcs);
 
diff --git a/drivers/gpu/drm/ttm/tests/ttm_tt_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
new file mode 100644
index ..4f5fc4d460b4
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_tt_test.c
@@ -0,0 +1,295 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+#define BO_SIZESZ_4K
+
+struct ttm_tt_test_case {
+   const char *description;
+   uint32_t size;
+   uint32_t extra_pages_num;
+};
+
+static int ttm_tt_test_init(struct kunit *test)
+{
+   struct ttm_test_devices *priv;
+
+   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, priv);
+
+   priv = ttm_test_devices_all(test);
+   test->priv = priv;
+
+   return 0;
+}
+
+static const struct ttm_tt_test_case ttm_tt_init_basic_cases[] = {
+   {
+   .description = "Page-aligned size",
+   .size = SZ_4K,
+   },
+   {
+   .description = "Extra pages requested",
+   .size = SZ_4K,
+   .extra_pages_num = 1,
+   },
+};
+
+static void ttm_tt_init_case_desc(const struct ttm_tt_test_case *t,
+ char *desc)
+{
+   strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+KUNIT_ARRAY_PARAM(ttm_tt_init_basic, ttm_tt_init_basic_cases,
+ ttm_tt_init_case_desc);
+
+static void ttm_tt_init_basic(struct kunit *test)
+{
+   const struct ttm_tt_test_case *params = test->param_value;
+   struct ttm_buffer_object *bo;
+   struct ttm_tt *tt;
+   uint32_t page_flags = TTM_TT_FLAG_ZERO_ALLOC;
+   enum ttm_caching caching = ttm_cached;
+   uint32_t extra_pages = params->extra_pages_num;
+   int num_pages = params->size >> PAGE_SHIFT;
+   int err;
+
+   tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, tt);
+
+   bo = ttm_bo_kunit_init(test, test->priv, params->size);
+
+   err = ttm_tt_init(tt, bo, page_flags, caching, extra_pages);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   KUNIT_ASSERT_EQ(test, tt->num_pages, num_pages + extra_pages);
+
+   KUNIT_ASSERT_EQ(test, tt->page_flags, page_flags);
+   KUNIT_ASSERT_EQ(test, tt->caching, caching);
+
+   KUNIT_ASSERT_NULL(test, tt->dma_address);
+   KUNIT_ASSERT_NULL(test, tt->swap_storage);
+}
+
+static void ttm_tt_init_misaligned(struct kunit *test)
+{
+   struct ttm_buffer_object *bo;
+   struct ttm_tt *tt;
+   enum ttm_caching caching = ttm_cached;
+   uint32_t size = SZ_8K;
+   int num_pages = (size + SZ_4K) >> PAGE_SHIFT;
+   int err;
+
+   tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, tt);
+
+   bo = ttm_bo_kunit_init(test, test->priv, size);
+
+   /* Make the object size misaligned */
+   bo->base.size += 1;
+
+   err = ttm_tt_init(tt, bo, 0, caching, 0);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   KUNIT_ASSERT_EQ(test,

[PATCH v6 7/8] drm/ttm/tests: Add tests with mock resource managers

[Karolina Stolarek]

Add mock resource manager to test ttm_bo_validate() with non-system
placements. Update KConfig entry to enable DRM Buddy allocator, used
by the mock manager. Update move function to do more than just assign
a resource.

Signed-off-by: Karolina Stolarek 
---
 drivers/gpu/drm/Kconfig   |   1 +
 drivers/gpu/drm/ttm/tests/.kunitconfig|   1 +
 drivers/gpu/drm/ttm/tests/Makefile|   1 +
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 275 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  39 ++-
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   2 +
 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c  | 194 
 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h  |  30 ++
 8 files changed, 541 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3eee8636f847..4256c0cea603 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -200,6 +200,7 @@ config DRM_TTM_KUNIT_TEST
 default n
 depends on DRM && KUNIT && MMU
 select DRM_TTM
+select DRM_BUDDY
 select DRM_EXPORT_FOR_TESTS if m
 select DRM_KUNIT_TEST_HELPERS
 default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/ttm/tests/.kunitconfig 
b/drivers/gpu/drm/ttm/tests/.kunitconfig
index 75fdce0cd98e..9228ce9b913c 100644
--- a/drivers/gpu/drm/ttm/tests/.kunitconfig
+++ b/drivers/gpu/drm/ttm/tests/.kunitconfig
@@ -2,3 +2,4 @@ CONFIG_KUNIT=y
 CONFIG_DRM=y
 CONFIG_DRM_KUNIT_TEST_HELPERS=y
 CONFIG_DRM_TTM_KUNIT_TEST=y
+CONFIG_DRM_BUDDY=y
diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index 2e5ed63fb414..f3149de77541 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -7,4 +7,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
 ttm_tt_test.o \
 ttm_bo_test.o \
 ttm_bo_validate_test.o \
+ttm_mock_manager.o \
 ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
index 38e584798584..f0f0ab992e04 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -8,12 +8,15 @@
 #include 
 
 #include "ttm_kunit_helpers.h"
+#include "ttm_mock_manager.h"
 
 #define BO_SIZESZ_4K
+#define MANAGER_SIZE   SZ_1M
 
 struct ttm_bo_validate_test_case {
const char *description;
enum ttm_bo_type bo_type;
+   uint32_t mem_type;
bool with_ttm;
 };
 
@@ -106,6 +109,49 @@ static void ttm_bo_init_reserved_sys_man(struct kunit 
*test)
ttm_bo_put(bo);
 }
 
+static void ttm_bo_init_reserved_mock_man(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+   struct ttm_placement *placement;
+   enum ttm_bo_type bo_type = params->bo_type;
+   struct ttm_operation_ctx ctx = { };
+   uint32_t mem_type = TTM_PL_VRAM;
+   uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+   int err;
+
+   ttm_mock_manager_init(priv->ttm_dev, mem_type, MANAGER_SIZE);
+
+   bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, bo);
+
+   place = ttm_place_kunit_init(test, mem_type, 0, size);
+   placement = ttm_placement_kunit_init(test, place, 1, NULL, 0);
+
+   drm_gem_private_object_init(priv->drm, &bo->base, size);
+
+   err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type, placement,
+  PAGE_SIZE, &ctx, NULL, NULL,
+  &dummy_ttm_bo_destroy);
+   dma_resv_unlock(bo->base.resv);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_EXPECT_EQ(test, kref_read(&bo->kref), 1);
+   KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
+   KUNIT_EXPECT_EQ(test, bo->type, bo_type);
+   KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
+
+   if (bo_type != ttm_bo_type_kernel)
+   KUNIT_EXPECT_TRUE(test,
+ 
drm_mm_node_allocated(&bo->base.vma_node.vm_node));
+
+   ttm_resource_free(bo, &bo->resource);
+   ttm_bo_put(bo);
+   ttm_mock_manager_fini(priv->ttm_dev, mem_type);
+}
+
 static void ttm_bo_init_reserved_resv(struct kunit *test)
 {
struct ttm_test_devices *priv = test->priv;
@@ -140,6 +186,52 @@ static void ttm_bo_init_reserved_resv(struct kunit *test)
ttm_bo_put(bo);
 }
 
+static void ttm_bo_validate_basic(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *fst_place, *snd_place;
+   st

[PATCH v6 8/8] drm/ttm/tests: Add test cases dependent on fence signaling

[Karolina Stolarek]

Add test cases that check how the state of dma fences in BO's
reservation object influence the ttm_bo_validation() flow. Do similar
tests for resource manager's move fence.

Signed-off-by: Karolina Stolarek 
---
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 306 ++
 1 file changed, 306 insertions(+)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
index f0f0ab992e04..2a15a7a1b476 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -2,6 +2,8 @@
 /*
  * Copyright © 2023 Intel Corporation
  */
+#include 
+#include 
 
 #include 
 #include 
@@ -13,11 +15,14 @@
 #define BO_SIZESZ_4K
 #define MANAGER_SIZE   SZ_1M
 
+static struct spinlock fence_lock;
+
 struct ttm_bo_validate_test_case {
const char *description;
enum ttm_bo_type bo_type;
uint32_t mem_type;
bool with_ttm;
+   bool no_gpu_wait;
 };
 
 static struct ttm_placement *ttm_placement_kunit_init(struct kunit *test,
@@ -39,6 +44,43 @@ static struct ttm_placement *ttm_placement_kunit_init(struct 
kunit *test,
return placement;
 }
 
+static const char *fence_name(struct dma_fence *f)
+{
+   return "ttm-bo-validate-fence";
+}
+
+static const struct dma_fence_ops fence_ops = {
+   .get_driver_name = fence_name,
+   .get_timeline_name = fence_name,
+};
+
+static struct dma_fence *alloc_mock_fence(struct kunit *test)
+{
+   struct dma_fence *fence;
+
+   fence = kunit_kzalloc(test, sizeof(*fence), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, fence);
+
+   dma_fence_init(fence, &fence_ops, &fence_lock, 0, 0);
+
+   return fence;
+}
+
+static void dma_resv_kunit_active_fence_init(struct kunit *test,
+struct dma_resv *resv,
+enum dma_resv_usage usage)
+{
+   struct dma_fence *fence;
+
+   fence = alloc_mock_fence(test);
+   dma_fence_enable_sw_signaling(fence);
+
+   dma_resv_lock(resv, NULL);
+   dma_resv_reserve_fences(resv, 1);
+   dma_resv_add_fence(resv, fence, usage);
+   dma_resv_unlock(resv);
+}
+
 static void ttm_bo_validate_case_desc(const struct ttm_bo_validate_test_case 
*t,
  char *desc)
 {
@@ -459,6 +501,263 @@ static void ttm_bo_validate_multihop(struct kunit *test)
ttm_mock_manager_fini(priv->ttm_dev, final_mem);
 }
 
+static const struct ttm_bo_validate_test_case ttm_bo_no_placement_cases[] = {
+   {
+   .description = "Buffer object in system domain, no page vector",
+   },
+   {
+   .description = "Buffer object in system domain with an existing 
page vector",
+   .with_ttm = true,
+   },
+};
+
+KUNIT_ARRAY_PARAM(ttm_bo_no_placement, ttm_bo_no_placement_cases,
+ ttm_bo_validate_case_desc);
+
+static void ttm_bo_validate_no_placement_signaled(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+   struct ttm_tt *old_tt;
+   struct ttm_placement *placement;
+   struct ttm_resource_manager *man;
+   uint32_t mem_type = TTM_PL_SYSTEM;
+   enum ttm_bo_type bo_type = ttm_bo_type_device;
+   struct ttm_operation_ctx ctx = { };
+   uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+   uint32_t flags;
+   int err;
+
+   place = ttm_place_kunit_init(test, mem_type, 0, size);
+   man = ttm_manager_type(priv->ttm_dev, mem_type);
+
+   bo = ttm_bo_kunit_init(test, test->priv, size);
+   bo->type = bo_type;
+
+   if (params->with_ttm) {
+   old_tt = priv->ttm_dev->funcs->ttm_tt_create(bo, 0);
+   ttm_pool_alloc(&priv->ttm_dev->pool, old_tt, &ctx);
+   bo->ttm = old_tt;
+   }
+
+   err = ttm_resource_alloc(bo, place, &bo->resource);
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_ASSERT_EQ(test, man->usage, size);
+
+   placement = kunit_kzalloc(test, sizeof(*placement), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, placement);
+
+   ttm_bo_reserve(bo, false, false, NULL);
+   err = ttm_bo_validate(bo, placement, &ctx);
+   dma_resv_unlock(bo->base.resv);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_ASSERT_EQ(test, man->usage, 0);
+   KUNIT_ASSERT_NOT_NULL(test, bo->ttm);
+   KUNIT_EXPECT_EQ(test, ctx.bytes_moved, 0);
+
+   if (params->with_ttm) {
+   flags = bo->ttm->page_flags;
+
+   KUNIT_ASSERT_PTR_EQ(test, bo->ttm, old_tt);
+   KUNIT_ASSERT_FALSE(test, flags & TTM_TT_FLAG_PRIV_POPULATED);
+   KUNIT_ASSERT_TRUE(test, flags & TTM_TT_FLAG_ZERO_ALLOC);
+   }
+
+   ttm_bo_put(bo);
+}
+
+static int threaded_dma_resv_signal(void *arg)
+{
+

[PATCH v6 4/8] drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

[Karolina Stolarek]

Remove a leftover definition of page order and pass an empty flag value
in ttm_pool_pre_populated().

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 
---
 drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
index 2d9cae8cd984..b97f7b6daf5b 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -78,10 +78,9 @@ static struct ttm_pool *ttm_pool_pre_populated(struct kunit 
*test,
struct ttm_test_devices *devs = priv->devs;
struct ttm_pool *pool;
struct ttm_tt *tt;
-   unsigned long order = __fls(size / PAGE_SIZE);
int err;
 
-   tt = ttm_tt_kunit_init(test, order, caching, size);
+   tt = ttm_tt_kunit_init(test, 0, caching, size);
KUNIT_ASSERT_NOT_NULL(test, tt);
 
pool = kunit_kzalloc(test, sizeof(*pool), GFP_KERNEL);
-- 
2.25.1

[PATCH v6 6/8] drm/ttm/tests: Test simple BO creation and validation

[Karolina Stolarek]

Add tests for ttm_bo_init_reserved() and ttm_bo_validate() that use
sys manager. Define a simple move function in ttm_device_funcs. Expose
destroy callback of the buffer object to make testing of
ttm_bo_init_reserved() behaviour easier.

Signed-off-by: Karolina Stolarek 
---
 drivers/gpu/drm/ttm/tests/Makefile|   1 +
 .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 211 ++
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  14 +-
 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   1 +
 4 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index 468535f7eed2..2e5ed63fb414 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
 ttm_resource_test.o \
 ttm_tt_test.o \
 ttm_bo_test.o \
+ttm_bo_validate_test.o \
 ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
new file mode 100644
index ..38e584798584
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -0,0 +1,211 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+#define BO_SIZESZ_4K
+
+struct ttm_bo_validate_test_case {
+   const char *description;
+   enum ttm_bo_type bo_type;
+   bool with_ttm;
+};
+
+static struct ttm_placement *ttm_placement_kunit_init(struct kunit *test,
+ struct ttm_place *places,
+ unsigned int num_places,
+ struct ttm_place 
*busy_places,
+ unsigned int 
num_busy_places)
+{
+   struct ttm_placement *placement;
+
+   placement = kunit_kzalloc(test, sizeof(*placement), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, placement);
+
+   placement->num_placement = num_places;
+   placement->placement = places;
+   placement->num_busy_placement = num_busy_places;
+   placement->busy_placement = busy_places;
+
+   return placement;
+}
+
+static void ttm_bo_validate_case_desc(const struct ttm_bo_validate_test_case 
*t,
+ char *desc)
+{
+   strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+static const struct ttm_bo_validate_test_case ttm_bo_type_cases[] = {
+   {
+   .description = "Buffer object for userspace",
+   .bo_type = ttm_bo_type_device,
+   },
+   {
+   .description = "Kernel buffer object",
+   .bo_type = ttm_bo_type_kernel,
+   },
+   {
+   .description = "Shared buffer object",
+   .bo_type = ttm_bo_type_sg,
+   },
+};
+
+KUNIT_ARRAY_PARAM(ttm_bo_types, ttm_bo_type_cases,
+ ttm_bo_validate_case_desc);
+
+static void ttm_bo_init_reserved_sys_man(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+   struct ttm_placement *placement;
+   enum ttm_bo_type bo_type = params->bo_type;
+   struct ttm_operation_ctx ctx = { };
+   uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+   int err;
+
+   bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, bo);
+
+   place = ttm_place_kunit_init(test, TTM_PL_SYSTEM, 0, size);
+   placement = ttm_placement_kunit_init(test, place, 1, NULL, 0);
+
+   drm_gem_private_object_init(priv->drm, &bo->base, size);
+
+   err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type, placement,
+  PAGE_SIZE, &ctx, NULL, NULL,
+  &dummy_ttm_bo_destroy);
+   dma_resv_unlock(bo->base.resv);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_EXPECT_EQ(test, kref_read(&bo->kref), 1);
+   KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
+   KUNIT_EXPECT_EQ(test, bo->type, bo_type);
+   KUNIT_EXPECT_EQ(test, bo->page_alignment, PAGE_SIZE);
+   KUNIT_EXPECT_PTR_EQ(test, bo->destroy, &dummy_ttm_bo_destroy);
+   KUNIT_EXPECT_EQ(test, bo->pin_count, 0);
+   KUNIT_EXPECT_NULL(test, bo->bulk_move);
+   KUNIT_EXPECT_NOT_NULL(test, bo->ttm);
+   KUNIT_EXPECT_FALSE(test, ttm_tt_is_populated(bo->ttm));
+   KUNIT_EXPECT_NOT_NULL(test, bo->base.resv->fences);
+   KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
+
+   if (bo_type != ttm_bo_type_kernel)
+   KUNIT_EXPECT_TRUE(test,
+ 
drm_mm_node_alloc

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave & Daniel -

I see Dave already sent the pull request for v6.7-rc1 fixes, but here's
some more.

drm-intel-next-fixes-2023-11-08:
drm/i915 fixes for v6.7-rc1:
- Fix null dereference when perf interface is not available
- Fix a -Wstringop-overflow warning
- Fix a -Wformat-truncation warning in intel_tc_port_init
- Flush WC GGTT only on required platforms
- Fix MTL HBR3 rate support on C10 phy and eDP
- Fix MTL notify_guc for multi-GT
- Bump GLK CDCLK frequency when driving multiple pipes
- Fix potential spectre vulnerability

BR,
Jani.

The following changes since commit 5258dfd4a6adb5f45f046b0dd2e73c680f880d9d:

  usb: typec: altmodes/displayport: fixup drm internal api change vs new user. 
(2023-10-27 07:55:41 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2023-11-08

for you to fetch changes up to 9506fba463fcbdf8c8b7af3ec9ee34360df843fe:

  drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init (2023-11-06 
14:42:58 +0200)


drm/i915 fixes for v6.7-rc1:
- Fix null dereference when perf interface is not available
- Fix a -Wstringop-overflow warning
- Fix a -Wformat-truncation warning in intel_tc_port_init
- Flush WC GGTT only on required platforms
- Fix MTL HBR3 rate support on C10 phy and eDP
- Fix MTL notify_guc for multi-GT
- Bump GLK CDCLK frequency when driving multiple pipes
- Fix potential spectre vulnerability


Arnd Bergmann (1):
  drm/i915/mtl: avoid stringop-overflow warning

Chaitanya Kumar Borah (1):
  drm/i915/mtl: Support HBR3 rate with C10 phy and eDP in MTL

Harshit Mogalapalli (1):
  i915/perf: Fix NULL deref bugs with drm_dbg() calls

Kunwu Chan (1):
  drm/i915: Fix potential spectre vulnerability

Nirmoy Das (3):
  drm/i915: Flush WC GGTT only on required platforms
  drm/i915/mtl: Apply notify_guc to all GTs
  drm/i915/tc: Fix -Wformat-truncation in intel_tc_port_init

Ville Syrjälä (1):
  drm/i915: Bump GLK CDCLK frequency when driving multiple pipes

 drivers/gpu/drm/i915/display/intel_cdclk.c  | 12 ++
 drivers/gpu/drm/i915/display/intel_dp.c |  2 +-
 drivers/gpu/drm/i915/display/intel_tc.c | 11 ++---
 drivers/gpu/drm/i915/gem/i915_gem_context.c |  1 +
 drivers/gpu/drm/i915/gt/intel_ggtt.c| 35 -
 drivers/gpu/drm/i915/gt/intel_rc6.c | 16 -
 drivers/gpu/drm/i915/i915_debugfs_params.c  |  9 +---
 drivers/gpu/drm/i915/i915_perf.c| 15 +++--
 8 files changed, 65 insertions(+), 36 deletions(-)

-- 
Jani Nikula, Intel

Re: [PATCH 17/22] powerpc: ps3: move udbg_shutdown_ps3gelic prototype

[Geoff Levand]

Hi Arnd,

On 11/8/23 12:58, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> Allmodconfig kernels produce a missing-prototypes warning:
> 
> arch/powerpc/platforms/ps3/gelic_udbg.c:239:6: error: no previous prototype 
> for 'udbg_shutdown_ps3gelic' [-Werror=missing-prototypes]
> 
> Move the declaration from a local header to asm/ps3.h where it can be
> seen from both the caller and the definition.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  arch/powerpc/include/asm/ps3.h   | 6 ++
>  arch/powerpc/platforms/ps3/gelic_udbg.c  | 1 +
>  drivers/net/ethernet/toshiba/ps3_gelic_net.h | 6 --
>  3 files changed, 7 insertions(+), 6 deletions(-)

Seems good to me.  I'll test it next chance I get.

Signed-off-by: Geoff Levand 

Re: [RFC PATCH 01/10] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Harry Wentland]

On 2023-11-08 06:40, Sebastian Wick wrote:
> On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen  wrote:
>>
>> On Tue, 7 Nov 2023 11:58:26 -0500
>> Harry Wentland  wrote:
>>
>>> On 2023-11-07 04:55, Pekka Paalanen wrote:
 On Mon, 6 Nov 2023 11:19:27 -0500
 Harry Wentland  wrote:

> On 2023-10-20 06:36, Pekka Paalanen wrote:
>> On Thu, 19 Oct 2023 10:56:40 -0400
>> Harry Wentland  wrote:
>>
>>> On 2023-10-10 12:13, Melissa Wen wrote:
 O 09/08, Harry Wentland wrote:
> Signed-off-by: Harry Wentland 
>>
>> ...
>>
 Also, with this new plane API in place, I understand that we will
 already need think on how to deal with the mixing between old drm color
 properties (color encoding and color range) and these new way of 
 setting
 plane color properties. IIUC, Pekka asked a related question about it
 when talking about CRTC automatic RGB->YUV (?)

>>>
>>> We'll still need to confirm whether we'll want to deprecate these
>>> existing properties. If we do that we'd want a client prop. Things
>>> should still work without deprecating them, if drivers just pick up
>>> after the initial encoding and range CSC.
>>>
>>> But realistically it might be better to deprecate them and turn them
>>> into explicit colorops.
>>
>> The existing properties would need to be explicitly reflected in the
>> new pipelines anyway, otherwise there would always be doubt at which
>> point of a pipeline the old properties apply, and they might even
>> need to change positions between pipelines.
>>
>> I think it is simply easier to just hide all old color related
>> properties when userspace sets the client-cap to enable pipelines. The
>> problem is to make sure to hide all old properties on all drivers that
>> support the client-cap.
>>
>> As a pipeline must be complete (describe everything that happens to
>> pixel values), it's going to be a flag day per driver.
>>
>> Btw. the plane FB YUV->RGB conversion needs a colorop in every pipeline
>> as well. Maybe it's purely informative and non-configurable, keyed by
>> FB pixel format, but still.
>>
>> We also need a colorop to represent sample filtering, e.g. bilinear,
>> like I think Sebastian may have mentioned in the past. Everything
>> before the sample filter happens "per tap" as Joshua Ashton put it, and
>> everything after it happens on the sample that was computed as a
>> weighted average of the filter tap inputs (texels).
>>
>> There could be colorops other than sample filtering that operate on
>> more than one sample at a time, like blur or sharpness. There could
>> even be colorops that change the image size like adding padding that
>> the following colorop hardware requires, and then yet another colorop
>> that clips that padding away. For an example, see
>> https://lists.freedesktop.org/archives/dri-devel/2023-October/427015.html
>>
>> If that padding and its color can affect the pipeline results of the
>> pixels near the padding (e.g. some convolution is applied with them,
>> which may be the reason why padding is necessary to begin with), then
>> it would be best to model it.
>>
>
> I hear you but I'm also somewhat shying away from defining this at this 
> point.

 Would you define them before the new UAPI is released though?

 I agree there is no need to have them in this patch series, but I think
 we'd hit the below problems if the UAPI is released without them.

> There are already too many things that need to happen and I will focus on 
> the
> actual color blocks (LUTs, matrices) first. We'll always be able to add a 
> new
> (read-only) colorop type to define scaling and tap behavior at any point 
> and
> a client is free to ignore a color pipeline if it doesn't find any 
> tap/scale
> info in it.

 How would userspace know to look for tap/scale info, if there is no
 upstream definition even on paper?

>>>
>>> So far OSes did not care about this. Whether that's good or bad is
>>> something everyone can answer for themselves.
>>>
>>> If you write a compositor and really need this you can just ignore
>>> color pipelines that don't have this, i.e., you'll probably want
>>> to wait with implementing color pipeline support until you have what
>>> you need from DRM/KMS.
>>>
>>> This is not to say I don't want to have support for Weston. But I'm
>>> wondering if we place too much importance on getting every little
>>> thing figured out whereas we could be making forward progress and
>>> address more aspects of a color pipeline in the future. There is a
>>> reason gamescope has made a huge difference in driving the color
>>> management work forward.
>>>
 And the opposite case, if someone writes userspace withou

Re: [RFC PATCH v2 00/17] Color Pipeline API w/ VKMS

[Harry Wentland]

On 2023-11-08 06:54, Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Harry Wentland 
>> Sent: Friday, October 20, 2023 2:51 AM
>> To: dri-devel@lists.freedesktop.org
>> Cc: wayland-de...@lists.freedesktop.org; Harry Wentland
>> ; Ville Syrjala ; 
>> Pekka
>> Paalanen ; Simon Ser ;
>> Melissa Wen ; Jonas Ådahl ; Sebastian
>> Wick ; Shashank Sharma
>> ; Alexander Goins ; Joshua
>> Ashton ; Michel Dänzer ; Aleix Pol
>> ; Xaver Hugl ; Victoria Brekenfeld
>> ; Sima ; Shankar, Uma
>> ; Naseer Ahmed ;
>> Christopher Braga ; Abhinav Kumar
>> ; Arthur Grillo ; Hector
>> Martin ; Liviu Dudau ; Sasha
>> McIntosh 
>> Subject: [RFC PATCH v2 00/17] Color Pipeline API w/ VKMS
>>
>> This is an early RFC set for a color pipeline API, along with a sample
>> implementation in VKMS. All the key API bits are here.
>> VKMS now supports two named transfer function colorops and we have an IGT
>> test that confirms that sRGB EOTF, followed by its inverse gives us expected
>> results within +/- 1 8 bpc codepoint value.
>>
>> This patchset is grouped as follows:
>>  - Patches 1-2: couple general patches/fixes
>>  - Patches 3-5: introduce kunit to VKMS
>>  - Patch 6: description of motivation and details behind the
>> Color Pipeline API. If you're reading nothing else
>> but are interested in the topic I highly recommend
>> you take a look at this.
>>  - Patches 7-15: Add core DRM API bits
>>  - Patches 15-17: VKMS implementation
>>
>> There are plenty of things that I would like to see here but haven't had a 
>> chance
>> to look at. These will (hopefully) be addressed in future iterations:
>>  - Abandon IOCTLs and discover colorops as clients iterate the pipeline
>>  - Add color_pipeline client cap and deprecate existing color encoding and
>>color range properties.
>>See https://lists.freedesktop.org/archives/dri-devel/2023-
>> September/422643.html
>>  - Add CTM colorop to VKMS
>>  - Add custom LUT colorops to VKMS
>>  - Add pre-blending 3DLUT with tetrahedral interpolation to VKMS
>>  - How to support HW which can't bypass entire pipeline?
>>  - Add ability to create colorops that don't have BYPASS
>>  - Can we do a LOAD / COMMIT model for LUTs (and other properties)?
>>
>> IGT tests can be found at
>> https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/merge_requests/1
>>
>> IGT patches are also being sent to the igt-dev mailing list.
>>
>> libdrm changes to support the new IOCTLs are at
>> https://gitlab.freedesktop.org/hwentland/drm/-/merge_requests/1
>>
>> If you prefer a gitlab MR for review you can find it at
>> https://gitlab.freedesktop.org/hwentland/linux/-/merge_requests/5
>>
>> A slightly different approach for a Color Pipeline API was sent by Uma 
>> Shankar
>> and can be found at https://patchwork.freedesktop.org/series/123024/
>>
>> The main difference is that his approach is not introducing a new DRM core 
>> object
>> but instead exposes color pipelines via blob properties.
>> There are pros and cons to both approaches.
> 
> Thanks Harry and all others who have actively contributed to the design and
> discussions thus far.
> 
> Due to other commitments, we couldn't participate in XDC this time and also
> the delay on our part. Our apologies.
> 
> We looked at the approach and are aligned to go with property-based design,
> with some suggestions. Will follow in comments in respective patches.
> We are also in process of trying this for Intel's hardware to identify if any 
> gaps.
> 

That's great to hear. Thanks, Uma.

Harry

> Regards,
> Uma Shankar
> 
>> v2:
>>  - Rebased on drm-misc-next
>>  - Introduce a VKMS Kunit so we can test LUT functionality in vkms_composer
>>  - Incorporate feedback in color_pipeline.rst doc
>>  - Add support for sRGB inverse EOTF
>>  - Add 2nd enumerated TF colorop to VKMS
>>  - Fix LUTs and some issues with applying LUTs in VKMS
>>
>> Cc: Ville Syrjala 
>> Cc: Pekka Paalanen 
>> Cc: Simon Ser 
>> Cc: Harry Wentland 
>> Cc: Melissa Wen 
>> Cc: Jonas Ådahl 
>> Cc: Sebastian Wick 
>> Cc: Shashank Sharma 
>> Cc: Alexander Goins 
>> Cc: Joshua Ashton 
>> Cc: Michel Dänzer 
>> Cc: Aleix Pol 
>> Cc: Xaver Hugl 
>> Cc: Victoria Brekenfeld 
>> Cc: Sima 
>> Cc: Uma Shankar 
>> Cc: Naseer Ahmed 
>> Cc: Christopher Braga 
>> Cc: Abhinav Kumar 
>> Cc: Arthur Grillo 
>> Cc: Hector Martin 
>> Cc: Liviu Dudau 
>> Cc: Sasha McIntosh 
>>
>> Harry Wentland (17):
>>   drm/atomic: Allow get_value for immutable properties on atomic drivers
>>   drm: Don't treat 0 as -1 in drm_fixp2int_ceil
>>   drm/vkms: Create separate Kconfig file for VKMS
>>   drm/vkms: Add kunit tests for VKMS LUT handling
>>   drm/vkms: Avoid reading beyond LUT array
>>   drm/doc/rfc: Describe why prescriptive color pipeline is needed
>>   drm/colorop: Introduce new drm_colorop mode object
>>   drm/colorop: Add TYPE property
>>   drm/color: Add 1D Curve subtype
>>   drm/colorop: Add BYPASS property
>>   drm/colorop: Add NEXT property
>>   drm/colorop: Add atomic stat

Re: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color pipeline is needed

[Harry Wentland]

On 2023-11-08 07:18, Shankar, Uma wrote:
> 
> 
>> -Original Message-
>> From: Harry Wentland 
>> Sent: Friday, October 20, 2023 2:51 AM
>> To: dri-devel@lists.freedesktop.org
>> Cc: wayland-de...@lists.freedesktop.org; Harry Wentland
>> ; Ville Syrjala ; 
>> Pekka
>> Paalanen ; Simon Ser ;
>> Melissa Wen ; Jonas Ådahl ; Sebastian
>> Wick ; Shashank Sharma
>> ; Alexander Goins ; Joshua
>> Ashton ; Michel Dänzer ; Aleix Pol
>> ; Xaver Hugl ; Victoria Brekenfeld
>> ; Sima ; Shankar, Uma
>> ; Naseer Ahmed ;
>> Christopher Braga ; Abhinav Kumar
>> ; Arthur Grillo ; Hector
>> Martin ; Liviu Dudau ; Sasha
>> McIntosh 
>> Subject: [RFC PATCH v2 06/17] drm/doc/rfc: Describe why prescriptive color
>> pipeline is needed
>>
>> v2:
>>  - Update colorop visualizations to match reality (Sebastian, Alex Hung)
>>  - Updated wording (Pekka)
>>  - Change BYPASS wording to make it non-mandatory (Sebastian)
>>  - Drop cover-letter-like paragraph from COLOR_PIPELINE Plane Property
>>section (Pekka)
>>  - Use PQ EOTF instead of its inverse in Pipeline Programming example 
>> (Melissa)
>>  - Add "Driver Implementer's Guide" section (Pekka)
>>  - Add "Driver Forward/Backward Compatibility" section (Sebastian, Pekka)
>>
>> Signed-off-by: Harry Wentland 
>> Cc: Ville Syrjala 
>> Cc: Pekka Paalanen 
>> Cc: Simon Ser 
>> Cc: Harry Wentland 
>> Cc: Melissa Wen 
>> Cc: Jonas Ådahl 
>> Cc: Sebastian Wick 
>> Cc: Shashank Sharma 
>> Cc: Alexander Goins 
>> Cc: Joshua Ashton 
>> Cc: Michel Dänzer 
>> Cc: Aleix Pol 
>> Cc: Xaver Hugl 
>> Cc: Victoria Brekenfeld 
>> Cc: Sima 
>> Cc: Uma Shankar 
>> Cc: Naseer Ahmed 
>> Cc: Christopher Braga 
>> Cc: Abhinav Kumar 
>> Cc: Arthur Grillo 
>> Cc: Hector Martin 
>> Cc: Liviu Dudau 
>> Cc: Sasha McIntosh 
>> ---
>>  Documentation/gpu/rfc/color_pipeline.rst | 347 +++
>>  1 file changed, 347 insertions(+)
>>  create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
>>
>> diff --git a/Documentation/gpu/rfc/color_pipeline.rst
>> b/Documentation/gpu/rfc/color_pipeline.rst
>> new file mode 100644
>> index ..af5f2ea29116
>> --- /dev/null
>> +++ b/Documentation/gpu/rfc/color_pipeline.rst
>> @@ -0,0 +1,347 @@
>> +
>> +Linux Color Pipeline API
>> +
>> +
>> +What problem are we solving?
>> +
>> +
>> +We would like to support pre-, and post-blending complex color
>> +transformations in display controller hardware in order to allow for
>> +HW-supported HDR use-cases, as well as to provide support to
>> +color-managed applications, such as video or image editors.
>> +
>> +It is possible to support an HDR output on HW supporting the Colorspace
>> +and HDR Metadata drm_connector properties, but that requires the
>> +compositor or application to render and compose the content into one
>> +final buffer intended for display. Doing so is costly.
>> +
>> +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and
>> +other operations to support color transformations. These operations are
>> +often implemented in fixed-function HW and therefore much more power
>> +efficient than performing similar operations via shaders or CPU.
>> +
>> +We would like to make use of this HW functionality to support complex
>> +color transformations with no, or minimal CPU or shader load.
>> +
>> +
>> +How are other OSes solving this problem?
>> +
>> +
>> +The most widely supported use-cases regard HDR content, whether video
>> +or gaming.
>> +
>> +Most OSes will specify the source content format (color gamut, encoding
>> +transfer function, and other metadata, such as max and average light 
>> levels) to a
>> driver.
>> +Drivers will then program their fixed-function HW accordingly to map
>> +from a source content buffer's space to a display's space.
>> +
>> +When fixed-function HW is not available the compositor will assemble a
>> +shader to ask the GPU to perform the transformation from the source
>> +content format to the display's format.
>> +
>> +A compositor's mapping function and a driver's mapping function are
>> +usually entirely separate concepts. On OSes where a HW vendor has no
>> +insight into closed-source compositor code such a vendor will tune
>> +their color management code to visually match the compositor's. On
>> +other OSes, where both mapping functions are open to an implementer they 
>> will
>> ensure both mappings match.
>> +
>> +This results in mapping algorithm lock-in, meaning that no-one alone
>> +can experiment with or introduce new mapping algorithms and achieve
>> +consistent results regardless of which implementation path is taken.
>> +
>> +Why is Linux different?
>> +===
>> +
>> +Unlike other OSes, where there is one compositor for one or more
>> +drivers, on Linux we have a many-to-many relationship. Many compositors;
>> many drivers.
>> +In addition each compositor vendor or community has their own view of
>> +

Re: [PATCH] drm/Makefile: Move tiny drivers before native drivers

[Huacai Chen]

Hi, Thomas,

On Wed, Nov 8, 2023 at 4:14 PM Thomas Zimmermann  wrote:
>
> Hi,
>
> thanks for the patch.
>
> Am 08.11.23 um 03:46 schrieb Huacai Chen:
> > After commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
> > device_initcall to subsys_initcall_sync") some Lenovo laptops get a blank
> > screen until the display manager starts.
> >
> > This regression occurs with such a Kconfig combination:
> > CONFIG_SYSFB=y
> > CONFIG_SYSFB_SIMPLEFB=y
> > CONFIG_DRM_SIMPLEDRM=y
> > CONFIG_DRM_I915=y  # Or other native drivers such as radeon, amdgpu
> >
> > If replace CONFIG_DRM_SIMPLEDRM with CONFIG_FB_SIMPLE (they use the same
> > device), there is no blank screen. The root cause is the initialization
> > order, and this order depends on the Makefile.
> >
> > FB_SIMPLE is before native DRM drivers (e.g. i915, radeon, amdgpu, and
> > so on), but DRM_SIMPLEDRM is after them. Thus, if we use FB_SIMPLE, I915
> > will takeover FB_SIMPLE, then no problem; and if we use DRM_SIMPLEDRM,
> > DRM_SIMPLEDRM will try to takeover I915, but fails to work.
>
> But what exactly is the problem? From the lengthy discussion threat, it
> looks like you've stumbled across a long-known problem, where the
> firmware driver probes a device that has already been taken by a native
> driver. But that should not be possible.
Yes, it is a long-known problem but only exposed after commit
60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
device_initcall to subsys_initcall_sync"), because the platform device
for simpledrm was not created as early as possible in old kernels.

>
> As you know, there's a platform device that represents the firmware
> framebuffer. The firmware drivers, such as simpledrm, bind to it. In
> i915 and the other native drivers we remove that platform device, so
> that simpledrm does not run.
>
> We call the DRM aperture helpers at [1]. It's implemented at [2]. The
> function contains a call to sysfb_disable(), [3] which should be invoked
> for the i915 device and remove the platform device.
Yes, this looks a little strange, which I haven't investigated before.
Jaak, could you please try to see whether sysfb_disable() is called in
bad kernels?

>
> [1]
> https://elixir.bootlin.com/linux/v6.5/source/drivers/gpu/drm/i915/i915_driver.c#L489
> [2]
> https://elixir.bootlin.com/linux/v6.5/source/drivers/video/aperture.c#L347
> [3]
> https://elixir.bootlin.com/linux/v6.5/source/drivers/firmware/sysfb.c#L63
>
> Can you investigate why this does not work? Is sysfb_disable() not being
> called? Does it remove the platform device?
>
> >
> > So we can move the "tiny" directory before native DRM drivers to solve
> > this problem.
>
> Relying on linking order is just as unreliable. The usual workaround is
> to build native drivers as modules. But first, please investigate where
> the current code fails.
Yes, native drivers are usually built as modules, but Jaak tries to
built-in, and then reports this bug. :)

Huacai

>
> Best regards
> Thomas
>
> >
> > Fixes: 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from 
> > device_initcall to subsys_initcall_sync")
> > Closes: 
> > https://lore.kernel.org/dri-devel/ZUnNi3q3yB3zZfTl@P70.localdomain/T/#t
> > Reported-by: Jaak Ristioja 
> > Signed-off-by: Huacai Chen 
> > ---
> >   drivers/gpu/drm/Makefile | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 8e1bde059170..db0f3d3aff43 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -141,6 +141,7 @@ obj-y += arm/
> >   obj-y   += display/
> >   obj-$(CONFIG_DRM_TTM)   += ttm/
> >   obj-$(CONFIG_DRM_SCHED) += scheduler/
> > +obj-y+= tiny/
> >   obj-$(CONFIG_DRM_RADEON)+= radeon/
> >   obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
> >   obj-$(CONFIG_DRM_AMDGPU)+= amd/amdxcp/
> > @@ -182,7 +183,6 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
> >   obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
> >   obj-y   += hisilicon/
> >   obj-y   += mxsfb/
> > -obj-y+= tiny/
> >   obj-$(CONFIG_DRM_PL111) += pl111/
> >   obj-$(CONFIG_DRM_TVE200) += tve200/
> >   obj-$(CONFIG_DRM_XEN) += xen/
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)

Re: [syzbot] [dri?] kernel BUG in vmf_insert_pfn_prot (2)

[syzbot]

syzbot has bisected this issue to:

commit 45d9c8dde4cd8589f9180309ec60f0da2ce486e4
Author: Daniel Vetter 
Date:   Thu Aug 12 13:14:12 2021 +

drm/vgem: use shmem helpers

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=126094df68
start commit:   d2f51b3516da Merge tag 'rtc-6.7' of git://git.kernel.org/p..
git tree:   upstream
final oops: https://syzkaller.appspot.com/x/report.txt?x=116094df68
console output: https://syzkaller.appspot.com/x/log.txt?x=166094df68
kernel config:  https://syzkaller.appspot.com/x/.config?x=1ffa1cec3b40f3ce
dashboard link: https://syzkaller.appspot.com/bug?extid=398e17b61dab22cc56bc
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=16344918e8
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=156bb2c0e8

Reported-by: syzbot+398e17b61dab22cc5...@syzkaller.appspotmail.com
Fixes: 45d9c8dde4cd ("drm/vgem: use shmem helpers")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: [PATCH] drm/Makefile: Move tiny drivers before native drivers

[Huacai Chen]

Hi, Javier,

On Wed, Nov 8, 2023 at 4:24 PM Javier Martinez Canillas
 wrote:
>
> Hello,
>
> On Wed, Nov 8, 2023 at 9:14 AM Thomas Zimmermann  wrote:
> >
> > Hi,
> >
>
> [...]
>
> >
> > Relying on linking order is just as unreliable. The usual workaround is
> > to build native drivers as modules. But first, please investigate where
> > the current code fails.
> >
>
> I fully agree with Thomas here. This is just papering over the issue.
>
> I'll read the lengthy thread now to see if I can better understand
> what's going on here.
Thank you very much.

Huacai

> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>

Re: kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 (different address spaces)

[Steven Rostedt]

On Wed, 8 Nov 2023 13:55:21 +0800
kernel test robot  wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   305230142ae0637213bf6e04f6d9f10bbcb74af8
> commit: c0a581d7126c0bbc96163276f585fd7b4e4d8d0e tracing: Disable interrupt 
> or preemption before acquiring arch_spinlock_t
> date:   1 year, 1 month ago
> config: loongarch-randconfig-r123-20231107 
> (https://download.01.org/0day-ci/archive/20231108/202311081340.3k72kkdg-...@intel.com/config)
> compiler: loongarch64-linux-gcc (GCC) 13.2.0
> reproduce: 
> (https://download.01.org/0day-ci/archive/20231108/202311081340.3k72kkdg-...@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version 
> of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot 
> | Closes: 
> https://lore.kernel.org/oe-kbuild-all/202311081340.3k72kkdg-...@intel.com/
> 
> sparse warnings: (new ones prefixed by >>)
>kernel/trace/trace.c:406:28: sparse: sparse: incorrect type in argument 1 
> (different address spaces) @@ expected struct trace_export **list @@ 
> got struct trace_export [noderef] __rcu ** @@
>kernel/trace/trace.c:406:28: sparse: expected struct trace_export 
> **list
>kernel/trace/trace.c:406:28: sparse: got struct trace_export [noderef] 
> __rcu **
>kernel/trace/trace.c:420:33: sparse: sparse: incorrect type in argument 1 
> (different address spaces) @@ expected struct trace_export **list @@ 
> got struct trace_export [noderef] __rcu ** @@
>kernel/trace/trace.c:420:33: sparse: expected struct trace_export 
> **list
>kernel/trace/trace.c:420:33: sparse: got struct trace_export [noderef] 
> __rcu **
> >> kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected void *ptr @@ got unsigned 
> >> int [noderef] __percpu * @@  
>kernel/trace/trace.c:2430:9: sparse: expected void *ptr
>kernel/trace/trace.c:2430:9: sparse: got unsigned int [noderef] 
> __percpu *
> >> kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected void *ptr @@ got unsigned 
> >> int [noderef] __percpu * @@  
>kernel/trace/trace.c:2430:9: sparse: expected void *ptr
>kernel/trace/trace.c:2430:9: sparse: got unsigned int [noderef] 
> __percpu *
> >> kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected void *ptr @@ got unsigned 
> >> int [noderef] __percpu * @@  
>kernel/trace/trace.c:2430:9: sparse: expected void *ptr
>kernel/trace/trace.c:2430:9: sparse: got unsigned int [noderef] 
> __percpu *
> >> kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected void *ptr @@ got unsigned 
> >> int [noderef] __percpu * @@  
>kernel/trace/trace.c:2430:9: sparse: expected void *ptr
>kernel/trace/trace.c:2430:9: sparse: got unsigned int [noderef] 
> __percpu *
> >> kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected void *ptr @@ got int 
> >> [noderef] __percpu * @@  
>kernel/trace/trace.c:2430:9: sparse: expected void *ptr
>kernel/trace/trace.c:2430:9: sparse: got int [noderef] __percpu *
> >> kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected void *ptr @@ got int 
> >> [noderef] __percpu * @@  
>kernel/trace/trace.c:2430:9: sparse: expected void *ptr
>kernel/trace/trace.c:2430:9: sparse: got int [noderef] __percpu *
> >> kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected void *ptr @@ got int 
> >> [noderef] __percpu * @@  
>kernel/trace/trace.c:2430:9: sparse: expected void *ptr
>kernel/trace/trace.c:2430:9: sparse: got int [noderef] __percpu *
> >> kernel/trace/trace.c:2430:9: sparse: sparse: incorrect type in argument 1 
> >> (different address spaces) @@ expected void *ptr @@ got int 
> >> [noderef] __percpu * @@  


> 
> vim +2430 kernel/trace/trace.c
> 
>   2410
>   2411static int trace_save_cmdline(struct task_struct *tsk)
>   2412{
>   2413unsigned tpid, idx;
>   2414
>   2415/* treat recording of idle task as a success */
>   2416 

Re: [Patch v2] drm/ttm: Schedule delayed_delete worker closer

[Christian König]

Am 08.11.23 um 13:58 schrieb Rajneesh Bhardwaj:

Try to allocate system memory on the NUMA node the device is closest to
and try to run delayed_delete workers on a CPU of this node as well.

To optimize the memory clearing operation when a TTM BO gets freed by
the delayed_delete worker, scheduling it closer to a NUMA node where the
memory was initially allocated helps avoid the cases where the worker
gets randomly scheduled on the CPU cores that are across interconnect
boundaries such as xGMI, PCIe etc.

This change helps USWC GTT allocations on NUMA systems (dGPU) and AMD
APU platforms such as GFXIP9.4.3.

Acked-by: Felix Kuehling 
Signed-off-by: Rajneesh Bhardwaj 


Reviewed-by: Christian König 

Going to push this to drm-misc-next.

Thanks,
Christian.


---

Changes in v2:
  - Absorbed the feedback provided by Christian in the commit message and
the comment.

  drivers/gpu/drm/ttm/ttm_bo.c | 8 +++-
  drivers/gpu/drm/ttm/ttm_device.c | 3 ++-
  2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 5757b9415e37..6f28a77a565b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -370,7 +370,13 @@ static void ttm_bo_release(struct kref *kref)
spin_unlock(&bo->bdev->lru_lock);
  
  			INIT_WORK(&bo->delayed_delete, ttm_bo_delayed_delete);

-   queue_work(bdev->wq, &bo->delayed_delete);
+
+   /* Schedule the worker on the closest NUMA node. This
+* improves performance since system memory might be
+* cleared on free and that is best done on a CPU core
+* close to it.
+*/
+   queue_work_node(bdev->pool.nid, bdev->wq, 
&bo->delayed_delete);
return;
}
  
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c

index 43e27ab77f95..72b81a2ee6c7 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -213,7 +213,8 @@ int ttm_device_init(struct ttm_device *bdev, struct 
ttm_device_funcs *funcs,
bdev->funcs = funcs;
  
  	ttm_sys_man_init(bdev);

-   ttm_pool_init(&bdev->pool, dev, NUMA_NO_NODE, use_dma_alloc, use_dma32);
+
+   ttm_pool_init(&bdev->pool, dev, dev_to_node(dev), use_dma_alloc, 
use_dma32);
  
  	bdev->vma_manager = vma_manager;

spin_lock_init(&bdev->lru_lock);

RE: [RFC PATCH v3 09/12] net: add support for skbs with unreadable frags

[David Laight]

From: Mina Almasry
> Sent: 06 November 2023 02:44
> 
> For device memory TCP, we expect the skb headers to be available in host
> memory for access, and we expect the skb frags to be in device memory
> and unaccessible to the host. We expect there to be no mixing and
> matching of device memory frags (unaccessible) with host memory frags
> (accessible) in the same skb.
> 
> Add a skb->devmem flag which indicates whether the frags in this skb
> are device memory frags or not.
> 
...
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 1fae276c1353..8fb468ff8115 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -805,6 +805,8 @@ typedef unsigned char *sk_buff_data_t;
>   *   @csum_level: indicates the number of consecutive checksums found in
>   *   the packet minus one that have been verified as
>   *   CHECKSUM_UNNECESSARY (max 3)
> + *   @devmem: indicates that all the fragments in this skb are backed by
> + *   device memory.
>   *   @dst_pending_confirm: need to confirm neighbour
>   *   @decrypted: Decrypted SKB
>   *   @slow_gro: state present at GRO time, slower prepare step required
> @@ -991,7 +993,7 @@ struct sk_buff {
>  #if IS_ENABLED(CONFIG_IP_SCTP)
>   __u8csum_not_inet:1;
>  #endif
> -
> + __u8devmem:1;
>  #if defined(CONFIG_NET_SCHED) || defined(CONFIG_NET_XGRESS)
>   __u16   tc_index;   /* traffic control index */
>  #endif
> @@ -1766,6 +1768,12 @@ static inline void skb_zcopy_downgrade_managed(struct 
> sk_buff *skb)
>   __skb_zcopy_downgrade_managed(skb);
>  }

Doesn't that bloat struct sk_buff?
I'm not sure there are any spare bits available.
Although CONFIG_NET_SWITCHDEV and CONFIG_NET_SCHED seem to
already add padding.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

[PATCH] fbdev: hyperv_fb: fix uninitialized local variable use

[Arnd Bergmann]

From: Arnd Bergmann 

When CONFIG_SYSFB is disabled, the hyperv_fb driver can now run into
undefined behavior on a gen2 VM, as indicated by this smatch warning:

drivers/video/fbdev/hyperv_fb.c:1077 hvfb_getmem() error: uninitialized symbol 
'base'.
drivers/video/fbdev/hyperv_fb.c:1077 hvfb_getmem() error: uninitialized symbol 
'size'.

Since there is no way to know the actual framebuffer in this configuration,
just return an allocation failure here, which should avoid the build
warning and the undefined behavior.

Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/r/202311070802.ycpvehaz-...@intel.com/
Fixes: a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
Signed-off-by: Arnd Bergmann 
---
 drivers/video/fbdev/hyperv_fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index bf59daf862fc..a80939fe2ee6 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1013,6 +1013,8 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
} else if (IS_ENABLED(CONFIG_SYSFB)) {
base = screen_info.lfb_base;
size = screen_info.lfb_size;
+   } else {
+   goto err1;
}
 
/*
-- 
2.39.2

Re: [PATCH v6 0/8] Improve test coverage of TTM

[Christian König]

Am 08.11.23 um 14:56 schrieb Karolina Stolarek:

Add tests for building blocks of the TTM subsystem, such as ttm_resource,
ttm_resource_manager, ttm_tt and ttm_buffer_object. This series covers
basic functions such as initialization, allocation and clean-up of each
struct. Testing of ttm_buffer_object also includes locking and unlocking
the object for validation, with special scenarios such as an interrupted
wait or deadlock.

Some of the test cases check the bulk move mechanism and how it interacts
with pinned buffers. This is to be seen if we want to add dedicated testing
for bulk move or not. The resource allocation subtests use ttm_sys_manager
for now. Resources that don't use system memory will be indirectly tested
via tests for ttm_bo_validate()/ttm_bo_init_validate(), using a mock
resource manager.

Use kunit_tool script to manually run all the tests:

$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/ttm/tests

To build a kernel with TTM KUnit tests, first enable CONFIG_KUNIT, and
then CONFIG_DRM_TTM_KUNIT_TEST.


Well, you have a tendency to keep us busy :)

Please keep Amar looped in those patches. I will try to review them when 
I have time, but he can give you at least some tested-by tags on AMD hw.


Thanks,
Christian.



Many thanks,
Karolina

v6:
   - Include tests for ttm_bo_init_reserved() and ttm_bo_validate(), with
 a mock resource manager (patches 6-8; no eviction testing)
   - Add ttm_test_devices_all_init() helper to also init ttm_device instance
   - Remove fpfn and lpfn from ttm_place_kunit_init() helper -- these fields
 are neither used nor tested

v5:
   - Actually use the page_flags parameter in ttm_tt_simple_create()

v4:
   - First unreserve the object before calling ww_acquire_fini() in
 ttm_bo_reserve_double_resv subtest
   - Silence lockdep in ttm_bo_reserve_deadlock subtest (open to suggestions
 how to fix it in a different way)
   - Use a genuine GEM object in ttm_buffer_object instead of an empty one

v3:
   - Instead of modifying the main TTM Makefile, use
 EXPORT_SYMBOL_FOR_TESTS_ONLY() macro for symbols that are tested but
 not widely exported. Thanks to this change, TTM tests can be built
 as modules, even when non-exported functions are used
   - Change the description of a patch that fixes ttm_pool_pre_populated()

v2:
   - Remove Makefile for KUnit tests and move the definitions to the
 TTM's one
   - Switch on CONFIG_DRM_TTM_KUNIT_TEST=m so the tests and TTM module
 are built as one. This allows building the tests as a module, even
 if it uses functions that are not exported
   - Fix ttm_pool_pre_populated(); a wrong flag was passed to
 ttm_tt_kunit_init() function

Karolina Stolarek (8):
   drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man
   drm/ttm/tests: Add tests for ttm_tt
   drm/ttm/tests: Add tests for ttm_bo functions
   drm/ttm/tests: Fix argument in ttm_tt_kunit_init()
   drm/ttm/tests: Use an init function from the helpers lib
   drm/ttm/tests: Test simple BO creation and validation
   drm/ttm/tests: Add tests with mock resource managers
   drm/ttm/tests: Add test cases dependent on fence signaling

  drivers/gpu/drm/Kconfig   |   1 +
  drivers/gpu/drm/ttm/tests/.kunitconfig|   1 +
  drivers/gpu/drm/ttm/tests/Makefile|   5 +
  drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 ++
  .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 792 ++
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 110 ++-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   8 +
  drivers/gpu/drm/ttm/tests/ttm_mock_manager.c  | 194 +
  drivers/gpu/drm/ttm/tests/ttm_mock_manager.h  |  30 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c |   3 +-
  drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 
  drivers/gpu/drm/ttm/tests/ttm_tt_test.c   | 282 +++
  drivers/gpu/drm/ttm/ttm_resource.c|   3 +
  drivers/gpu/drm/ttm/ttm_tt.c  |   3 +
  14 files changed, 2383 insertions(+), 3 deletions(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_tt_test.c

Re: [PATCH 17/22] powerpc: ps3: move udbg_shutdown_ps3gelic prototype

[Jakub Kicinski]

On Wed, 8 Nov 2023 14:18:09 + Geoff Levand wrote:
> Seems good to me.  I'll test it next chance I get.
> 
> Signed-off-by: Geoff Levand 

Seems like this is best routed via powerpc:

Acked-by: Jakub Kicinski 

Re: [PATCH 0/4] accel/ivpu: Use GEM shmem

[Jacek Lawrynowicz]

Applied to drm-misc-next

On 31.10.2023 08:31, Stanislaw Gruszka wrote:
> Use GEM shmem for buffer management code;
> 
> Previously sent as RFC:
> https://lore.kernel.org/dri-devel/20230901164842.178654-1-stanislaw.grus...@linux.intel.com/
> 
> Compared to RFC only changelog's were improved.
> 
> Jacek Lawrynowicz (4):
>   accel/ivpu: Allocate vpu_addr in gem->open() callback
>   accel/ivpu: Fix locking in ivpu_bo_remove_all_bos_from_context()
>   accel/ivpu: Remove support for uncached buffers
>   accel/ivpu: Use GEM shmem helper for all buffers
> 
>  drivers/accel/ivpu/Kconfig|   2 +-
>  drivers/accel/ivpu/ivpu_drv.c |  13 +-
>  drivers/accel/ivpu/ivpu_drv.h |   3 +
>  drivers/accel/ivpu/ivpu_fw.c  |   2 +-
>  drivers/accel/ivpu/ivpu_gem.c | 678 --
>  drivers/accel/ivpu/ivpu_gem.h |  75 +--
>  drivers/accel/ivpu/ivpu_job.c |   8 +-
>  drivers/accel/ivpu/ivpu_mmu.c |   5 +-
>  drivers/accel/ivpu/ivpu_mmu_context.c |  38 +-
>  drivers/accel/ivpu/ivpu_mmu_context.h |  11 +-
>  include/uapi/drm/ivpu_accel.h |   2 +-
>  11 files changed, 266 insertions(+), 571 deletions(-)
> 

Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state

[Maxime Ripard]

Hi,

Thanks for your answer

On Tue, Nov 07, 2023 at 04:26:34PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 07, 2023 at 01:18:14PM +0100, Maxime Ripard wrote:
> > On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote:
> > > > +GKH
> > > 
> > > Why?  I don't see a question for me here, sorry.
> > 
> > I guess the question is: we have a bus with various power states
> > (powered off, low power, high speed)
> 
> Great, have fun!  And is this per-device or per-bus-instance?

Per bus instance

> > low power is typically used to send commands to a device, high speed to
> > transmit pixels, but still allows to send commands.
> > 
> > Depending on the devices, there's different requirements about the state
> > devices expect the bus to be in to send commands. Some will need to send
> > all the commands in the low power state, some don't care, etc. See
> > the mail I was replying too for more details.
> > 
> > We've tried so far to model that in KMS itself, so the framework the
> > drivers would register too, but we're kind of reaching the limits of
> > what we can do there. It also feels to me that "the driver can't access
> > its device" is more of a problem for the bus to solve rather than the
> > framework.
> 
> This is up to the specific bus to resolve, there's nothing special
> needed in the driver core for it, right?

Yeah, we weren't really looking to handle this into the driver core, but
rather if there was a set of guidelines or feedback on implementing
those kind of features for a bus.

> > Do you agree? Are you aware of any other bus in Linux with similar
> > requirements we could look at? Or any suggestion on how to solve it?
> 
> There might be others, yes, look at how the dynamic power management
> works for different devices on most busses, that might help you out
> here.

Thanks for the pointers, we'll have a look
Maxime


signature.asc
Description: PGP signature

Re: [PATCH v6 1/5] drm/panel-edp: drm/panel-edp: Fix AUO B116XAK01 name and timing

[Maxime Ripard]

On Tue, 7 Nov 2023 12:41:51 -0800, Hsin-Yi Wang wrote:
> Rename AUO 0x405c B116XAK01 to B116XAK01.0 and adjust the timing of
> auo_b116xak01: T3=200, T12=500, T7_max = 50 according to decoding edid
> and datasheet.
> 
> Fixes: da458286a5e2 ("drm/panel: Add support for AUO B116XAK01 panel")
> 
> [ ... ]

Acked-by: Maxime Ripard 

Thanks!
Maxime

Re: [PATCH v6 2/5] drm/panel-edp: drm/panel-edp: Fix AUO B116XTN02 name

[Maxime Ripard]

On Tue, 7 Nov 2023 12:41:52 -0800, Hsin-Yi Wang wrote:
> Rename AUO 0x235c B116XTN02 to B116XTN02.3 according to decoding edid.
> 
> Fixes: 3db2420422a5 ("drm/panel-edp: Add AUO B116XTN02, BOE 
> NT116WHM-N21,836X2, NV116WHM-N49 V8.0")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Hsin-Yi Wang 
> 
> [ ... ]

Acked-by: Maxime Ripard 

Thanks!
Maxime

Re: [RFC PATCH v3 10/12] tcp: RX path for devmem TCP

[Edward Cree]

On 06/11/2023 21:17, Stanislav Fomichev wrote:
> I guess I'm just wondering whether other people have any suggestions
> here. Not sure Jonathan's way was better, but we fundamentally
> have two queues between the kernel and the userspace:
> - userspace receiving tokens (recvmsg + magical flag)
> - userspace refilling tokens (setsockopt + magical flag)
> 
> So having some kind of shared memory producer-consumer queue feels natural.
> And using 'classic' socket api here feels like a stretch, idk.

Do 'refilled tokens' (returned memory areas) get used for anything other
 than subsequent RX?  If not then surely the way to return a memory area
 in an io_uring idiom is just to post a new read sqe ('RX descriptor')
 pointing into it, rather than explicitly returning it with setsockopt.
(Being async means you can post lots of these, unlike recvmsg(), so you
 don't need any kernel management to keep the RX queue filled; it can
 just be all handled by the userland thus simplifying APIs overall.)
Or I'm misunderstanding something?

-e

Re: [PATCH v6 3/5] drm/panel-edp: drm/panel-edp: Add several generic edp panels

[Maxime Ripard]

On Tue, 7 Nov 2023 12:41:53 -0800, Hsin-Yi Wang wrote:
> Add a few generic edp panels used by mt8186 chromebooks.
> 
> Signed-off-by: Hsin-Yi Wang 
> Reviewed-by: Douglas Anderson 

Acked-by: Maxime Ripard 

Thanks!
Maxime

Re: [PATCH] fbdev: hyperv_fb: fix uninitialized local variable use

[Helge Deller]

On 11/8/23 15:58, Arnd Bergmann wrote:

From: Arnd Bergmann 

When CONFIG_SYSFB is disabled, the hyperv_fb driver can now run into
undefined behavior on a gen2 VM, as indicated by this smatch warning:

drivers/video/fbdev/hyperv_fb.c:1077 hvfb_getmem() error: uninitialized symbol 
'base'.
drivers/video/fbdev/hyperv_fb.c:1077 hvfb_getmem() error: uninitialized symbol 
'size'.

Since there is no way to know the actual framebuffer in this configuration,
just return an allocation failure here, which should avoid the build
warning and the undefined behavior.

Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Closes: https://lore.kernel.org/r/202311070802.ycpvehaz-...@intel.com/
Fixes: a07b50d80ab6 ("hyperv: avoid dependency on screen_info")
Signed-off-by: Arnd Bergmann 


applied.

Thanks!
Helge



---
  drivers/video/fbdev/hyperv_fb.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index bf59daf862fc..a80939fe2ee6 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -1013,6 +1013,8 @@ static int hvfb_getmem(struct hv_device *hdev, struct 
fb_info *info)
} else if (IS_ENABLED(CONFIG_SYSFB)) {
base = screen_info.lfb_base;
size = screen_info.lfb_size;
+   } else {
+   goto err1;
}

/*