Re: [PATCH] drm/amdkfd: Replace one-element array with flexible-array member

2022-02-17 Thread Christian König
Felix need to comment as well, but I don't think that this will work 
that easily.


By changing the entry from 1 to 0 your are also changing the size of the 
structure.


Regards,
Christian.

Am 18.02.22 um 04:09 schrieb cgel@gmail.com:

From: Changcheng Deng 

There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use "flexible array members" for these cases. The older
style of one-element or zero-length arrays should no longer be used.
Reference:
https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays

Reported-by: Zeal Robot 
Signed-off-by: Changcheng Deng 
---
  drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
index 482ba84a728d..d7c38fbc533e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
@@ -310,7 +310,7 @@ struct cdit_header {
uint32_tcreator_revision;
uint32_ttotal_entries;
uint16_tnum_domains;
-   uint8_t entry[1];
+   uint8_t entry[];
  };
  
  #pragma pack()




Re: [PATCH] drm/amdgpu: check vm bo eviction valuable at last

2022-02-17 Thread Christian König

Am 18.02.22 um 04:08 schrieb Qiang Yu:

On Thu, Feb 17, 2022 at 8:22 PM Christian König
 wrote:

Am 17.02.22 um 11:58 schrieb Qiang Yu:

On Thu, Feb 17, 2022 at 6:39 PM Christian König
 wrote:


Am 17.02.22 um 11:13 schrieb Qiang Yu:

On Thu, Feb 17, 2022 at 5:46 PM Christian König
 wrote:

Am 17.02.22 um 10:40 schrieb Qiang Yu:

On Thu, Feb 17, 2022 at 5:15 PM Christian König
 wrote:

Am 17.02.22 um 10:04 schrieb Qiang Yu:

Workstation application ANSA/META get this error dmesg:
[drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-16)

This is caused by:
1. create a 256MB buffer in invisible VRAM
2. CPU map the buffer and access it causes vm_fault and try to move
it to visible VRAM
3. force visible VRAM space and traverse all VRAM bos to check if
evicting this bo is valuable
4. when checking a VM bo (in invisible VRAM), amdgpu_vm_evictable()
will set amdgpu_vm->evicting, but latter due to not in visible
VRAM, won't really evict it so not add it to amdgpu_vm->evicted
5. before next CS to clear the amdgpu_vm->evicting, user VM ops
ioctl will pass amdgpu_vm_ready() (check amdgpu_vm->evicted)
but fail in amdgpu_vm_bo_update_mapping() (check
amdgpu_vm->evicting) and get this error log

This error won't affect functionality as next CS will finish the
waiting VM ops. But we'd better make the amdgpu_vm->evicting
correctly reflact the vm status and clear the error log.

Well NAK, that is intentional behavior.

The VM page tables where considered for eviction, so setting the flag is
correct even when the page tables later on are not actually evicted.


But this will unnecessarily stop latter user VM ops in ioctl before CS
even when the VM bos are not evicted.
Won't this have any negative effect when could do better?

No, this will have a positive effect. See the VM was already considered
for eviction because it is idle.

Updating it immediately doesn't necessarily make sense, we should wait
with that until its next usage.

Additional to that this patch doesn't really fix the problem, it just
mitigates it.

Eviction can fail later on for a couple of reasons and we absolutely
need to check the flag instead of the list in amdgpu_vm_ready().

The flag only for both flag and list? Looks like should be both as
the list indicate some vm page table need to be updated and could
delay the user update with the same logic as you described above.

I think checking the flag should be enough. The issue is that the list
was there initially, but to avoid race conditions we added the flag with
separate lock protection later on.


But list and flag does not align always, there are cases like
list-empty/flag-set (this problem) and list-non-empty/flag-unset (non-vm bo
eviction). If only check flag list-non-empty/flag-unset change behavior.

Yeah, but I think that the flag unset list-non-empty case would be
correctly handled if we only test the flag.

In other words we can update the page tables as long as they are not
partially or fully evicted and that's not the case when non-vm BOs are
evicted.


This sounds like two standard for the same thing, because this problem
does not evict page tables too. But I see your point is:
There's a difference that this problem's case can make sure vm is idle,
and we prefer to delay vm updates when vm is idle.

If so, why not just stop user vm update by checking vm busy in
amdgpu_gem_va_ioctl() to skip amdgpu_gem_va_update_vm()?


That's exactly what amdgpu_gem_va_update_vm() is doing by calling 
amdgpu_vm_ready(). The problem is that amdgpu_vm_ready() looks at the 
wrong thing.



Then we can keep the evicting flag accurate (after solving your
concern for this patch that eviction may fail latter by further delay
the flag update after eviction success).


That won't work. See we need to mark the VM as evicted before we 
actually evict them because otherwise somebody could use the VM in 
parallel and add another fence to it.


Regards,
Christian.



Regards,
Qiang



Regards,
Christian.


Regards,
Qiang


Regards,
Christian.


Regards,
Qiang


Regards,
Christian.


Regards,
Qiang


What we should rather do is to fix amdgpu_vm_ready() to take a look at
the flag instead of the linked list.

Regards,
Christian.


Signed-off-by: Qiang Yu 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 85 ++---
  1 file changed, 47 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 5a32ee66d8c8..88a27911054f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1306,45 +1306,11 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
*adev, struct ttm_tt *ttm,
  return flags;
  }

-/*
- * amdgpu_ttm_bo_eviction_valuable - Check to see if we can evict a buffer
- * object.
- *
- * Return true if eviction is sensible. Called by ttm_mem_evict_first() on
- * behalf of 

[bug report] drm/amdkfd: CRIU checkpoint and restore queue mqds

2022-02-17 Thread Dan Carpenter
Hello David Yat Sin,

The patch 42c6c48214b7: "drm/amdkfd: CRIU checkpoint and restore
queue mqds" from Jan 25, 2021, leads to the following Smatch static
checker warning:

drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_mqd_manager_v9.c:344 
restore_mqd()
error: 'ctl_stack_size' from user is not capped properly

drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
   762int kfd_criu_restore_queue(struct kfd_process *p,
   763   uint8_t __user *user_priv_ptr,
   764   uint64_t *priv_data_offset,
   765   uint64_t max_priv_data_size)
   766{
   767uint8_t *mqd, *ctl_stack, *q_extra_data = NULL;
   768struct kfd_criu_queue_priv_data *q_data;
   769struct kfd_process_device *pdd;
   770uint64_t q_extra_data_size;
   771struct queue_properties qp;
   772unsigned int queue_id;
   773int ret = 0;
   774
   775if (*priv_data_offset + sizeof(*q_data) > 
max_priv_data_size)
   776return -EINVAL;
   777
   778q_data = kmalloc(sizeof(*q_data), GFP_KERNEL);
   779if (!q_data)
   780return -ENOMEM;
   781
   782ret = copy_from_user(q_data, user_priv_ptr + 
*priv_data_offset, sizeof(*q_data));
   783if (ret) {
   784ret = -EFAULT;
   785goto exit;
   786}
   787
   788*priv_data_offset += sizeof(*q_data);
   789q_extra_data_size = q_data->ctl_stack_size + 
q_data->mqd_size;
  ^^
ctl_stack_size comes from the user a couple lines earlier.  It's a u32
and so is q_data->mqd_size.  This addition can have an integer overflow.

   790
   791if (*priv_data_offset + q_extra_data_size > 
max_priv_data_size) {'
  
^^
Which means that this limit check doesn't work.

   792ret = -EINVAL;
   793goto exit;
   794}
   795
   796q_extra_data = kmalloc(q_extra_data_size, GFP_KERNEL);
   797if (!q_extra_data) {
   798ret = -ENOMEM;
   799goto exit;
   800}
   801
   802ret = copy_from_user(q_extra_data, user_priv_ptr + 
*priv_data_offset, q_extra_data_size);
   803if (ret) {
   804ret = -EFAULT;
   805goto exit;
   806}


regards,
dan carpenter


[PATCH] drm/panel: Add panel-edp: add lcd innolux,n140hca-eac

2022-02-17 Thread Rex Nie
innolux,n140hca-eac is a eDP-based LCD panel. This panel has 1920x1080
resolution in 14-inch TFT panel.

Signed-off-by: Rex Nie 
---
 .../display/panel/innolux,n140hca-eac.yaml| 43 +++
 drivers/gpu/drm/panel/panel-edp.c | 26 +++
 2 files changed, 69 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,n140hca-eac.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,n140hca-eac.yaml 
b/Documentation/devicetree/bindings/display/panel/innolux,n140hca-eac.yaml
new file mode 100644
index ..5493e383c97c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,n140hca-eac.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/innolux,n140hca-eac.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Innolux N140HCA-EAC 14 inch eDP 1080p display panel
+
+maintainers:
+  - Sandeep Panda 
+  - Douglas Anderson 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: innolux,n140hca-eac
+
+  enable-gpios: true
+  power-supply: true
+  backlight: true
+  no-hpd: true
+
+required:
+  - compatible
+  - power-supply
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+panel_edp: panel-edp {
+compatible = "innolux,n140hca-eac";
+enable-gpios = < 96 GPIO_ACTIVE_HIGH>;
+power-supply = <_disp_x>;
+backlight = <_lcd0>;
+no-hpd;
+};
+
+...
diff --git a/drivers/gpu/drm/panel/panel-edp.c 
b/drivers/gpu/drm/panel/panel-edp.c
index f7bfcf63d48e..f5f9c9cb26ba 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1330,6 +1330,29 @@ static const struct panel_desc innolux_n125hce_gn1 = {
},
 };
 
+static const struct display_timing innolux_n140hca_eac_timing = {
+   .pixelclock = { 7260, 7642, 8024 },
+   .hactive = { 1920, 1920, 1920 },
+   .hfront_porch = { 80, 80, 80 },
+   .hback_porch = { 190, 190, 190 },
+   .hsync_len = { 60, 60, 60 },
+   .vactive = { 1080, 1080, 1080 },
+   .vfront_porch = { 6, 6, 6 },
+   .vback_porch = { 38, 38, 38 },
+   .vsync_len = { 8, 8, 8 },
+   .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
+};
+
+static const struct panel_desc innolux_n140hca_eac = {
+   .timings = _n140hca_eac_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 309,
+   .height = 174,
+   },
+};
+
 static const struct drm_display_mode innolux_p120zdg_bf1_mode = {
.clock = 206016,
.hdisplay = 2160,
@@ -1750,6 +1773,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,n125hce-gn1",
.data = _n125hce_gn1,
+   }, {
+   .compatible = "innolux,n140hca-eac",
+   .data = _n140hca_eac,
}, {
.compatible = "innolux,p120zdg-bf1",
.data = _p120zdg_bf1,
-- 
2.25.1



Re: [PATCH v4 2/5] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

2022-02-17 Thread Bjorn Andersson
On Thu 17 Feb 17:03 PST 2022, Doug Anderson wrote:

> Hi,
> 
> On Thu, Feb 10, 2022 at 3:58 AM Sankeerth Billakanti
>  wrote:
> >
> > +   backlight_3v3_regulator: backlight-3v3-regulator {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "backlight_3v3_regulator";
> > +
> > +   regulator-min-microvolt = <330>;
> > +   regulator-max-microvolt = <330>;
> > +
> > +   gpio = <_gpios 7 GPIO_ACTIVE_HIGH>;
> > +   enable-active-high;
> > +
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_bl_power>;
> > +   };
> 
> So I'm pretty sure that this is wrong and what you had on a previous
> patch was more correct. Specifically the PMIC's GPIO 7 truly _is_ an
> enable pin for the backlight. In the schematics I see it's named as
> "PMIC_EDP_BL_EN" and is essentially the same net as "EDP_BL_EN". This
> is distinct from the backlight _regulator_ that is named VREG_EDP_BP.
> I believe the VREG_EDP_BP is essentially sourced directly from
> PPVAR_SYS. That's how it works on herobrine and I believe that CRD is
> the same. You currently don't model ppvar_sys, but it's basically just
> a variable-voltage rail that could be provided somewhat directly from
> the battery or could be provided from Type C components. I believe
> that the panel backlight is designed to handle this fairly wide
> voltage range and it's done this way to get the best efficiency.
> 
> So personally I'd prefer if you do something like herobrine and model
> PPVAR_SYS. Then the backlight can use ppvar_sys as its regulator and
> you can go back to providing this as an "enable" pin for the
> backlight.
> 
> I know, technically it doesn't _really_ matter, but it's nice to model
> it more correctly.

While I've not seen your schematics, the proposal does look similar to
what I have on sc8180x, where there's a power rail, the BL_EN and a pwm
signal.

If that's the case I think representing BL_EN using the enable-gpios
property directly in the pwm-backlight node seems more appropriate (with
power-supply being the actual thing that powers the backlight).

If however gpio 7 is wired to something like the enable-pin on an actual
LDO the proposal here seems reasonable, but it seems unlikely that the
output of that would be named "backlight_3v3_regulator"?

Regards,
Bjorn


Re: [Intel-gfx] [PATCH v5 09/19] Doc/gpu/rfc/i915: i915 DG2 64k pagesize uAPI

2022-02-17 Thread Lucas De Marchi

On Tue, Feb 01, 2022 at 04:11:22PM +0530, Ramalingam C wrote:

Details of the 64k pagesize support added as part of DG2 enabling and its
implicit impact on the uAPI.

v2: improvised the Flat-CCS documentation [Danvet & CQ]
v3: made only for 64k pagesize support

Signed-off-by: Ramalingam C 
cc: Daniel Vetter 
cc: Matthew Auld 
cc: Simon Ser 
cc: Pekka Paalanen 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye 
Cc: Slawomir Milczarek 
---
Documentation/gpu/rfc/i915_dg2.rst | 25 +
Documentation/gpu/rfc/index.rst|  3 +++
2 files changed, 28 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_dg2.rst

diff --git a/Documentation/gpu/rfc/i915_dg2.rst 
b/Documentation/gpu/rfc/i915_dg2.rst
new file mode 100644
index ..f4eb5a219897
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_dg2.rst
@@ -0,0 +1,25 @@
+
+I915 DG2 RFC Section
+
+
+Upstream plan
+=
+Plan to upstream the DG2 enabling is:
+
+* Merge basic HW enabling for DG2 (Still without pciid)
+* Merge the 64k support for lmem
+* Merge the flat CCS enabling patches
+* Add the pciid for DG2 and enable the DG2 in CI


does this make sense after the fact? Earlier version of this patch
Daniel Vetter asked this to be moved to the be the first patch. I see
you added it in the cover letter, but keeping this in
gpu/rfc/i915_dg2.rst doesn't make much sense IMO. Maybe just drop this
patch?

Lucas De Marchi


+
+
+64K page support for lmem
+=
+On DG2 hw, local-memory supports minimum GTT page size of 64k only. 4k is not
+supported anymore.
+
+DG2 hw doesn't support the 64k (lmem) and 4k (smem) pages in the same ppgtt
+Page table. Refer the struct drm_i915_gem_create_ext for the implication of
+handling the 64k page size.
+
+.. kernel-doc:: include/uapi/drm/i915_drm.h
+:functions: drm_i915_gem_create_ext
diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
index 91e93a705230..afb320ed4028 100644
--- a/Documentation/gpu/rfc/index.rst
+++ b/Documentation/gpu/rfc/index.rst
@@ -20,6 +20,9 @@ host such documentation:

i915_gem_lmem.rst

+.. toctree::
+i915_dg2.rst
+
.. toctree::

i915_scheduler.rst
--
2.20.1



Re: [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support

2022-02-17 Thread Jordan Justen
Robert Beckett  writes:

> From: Matthew Auld 
>
> On discrete platforms like DG2, we need to support a minimum page size
> of 64K when dealing with device local-memory. This is quite tricky for
> various reasons, so try to document the new implicit uapi for this.
>
> v3: fix typos and less emphasis
> v2: Fixed suggestions on formatting [Daniel]
>
> Signed-off-by: Matthew Auld 
> Signed-off-by: Ramalingam C 
> Signed-off-by: Robert Beckett 
> Acked-by: Jordan Justen 
> Reviewed-by: Ramalingam C 
> Reviewed-by: Thomas Hellström 
> cc: Simon Ser 
> cc: Pekka Paalanen 
> Cc: Jordan Justen 
> Cc: Kenneth Graunke 
> Cc: mesa-...@lists.freedesktop.org
> Cc: Tony Ye 
> Cc: Slawomir Milczarek 
> ---
>  include/uapi/drm/i915_drm.h | 44 -
>  1 file changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 5e678917da70..77e5e74c32c1 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
>   /**
>* When the EXEC_OBJECT_PINNED flag is specified this is populated by
>* the user with the GTT offset at which this object will be pinned.
> +  *
>* When the I915_EXEC_NO_RELOC flag is specified this must contain the
>* presumed_offset of the object.
> +  *
>* During execbuffer2 the kernel populates it with the value of the
>* current GTT offset of the object, for future presumed_offset writes.
> +  *
> +  * See struct drm_i915_gem_create_ext for the rules when dealing with
> +  * alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
> +  * minimum page sizes, like DG2.
>*/
>   __u64 offset;
>  
> @@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
>*
>* The (page-aligned) allocated size for the object will be returned.
>*
> -  * Note that for some devices we have might have further minimum
> -  * page-size restrictions(larger than 4K), like for device local-memory.
> -  * However in general the final size here should always reflect any
> -  * rounding up, if for example using the 
> I915_GEM_CREATE_EXT_MEMORY_REGIONS
> -  * extension to place the object in device local-memory.
> +  *
> +  * DG2 64K min page size implications:
> +  *
> +  * On discrete platforms, starting from DG2, we have to contend with GTT
> +  * page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
> +  * objects.  Specifically the hardware only supports 64K or larger GTT
> +  * page sizes for such memory. The kernel will already ensure that all
> +  * I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
> +  * sizes underneath.
> +  *
> +  * Note that the returned size here will always reflect any required
> +  * rounding up done by the kernel, i.e 4K will now become 64K on devices
> +  * such as DG2.
> +  *
> +  * Special DG2 GTT address alignment requirement:
> +  *
> +  * The GTT alignment will also need to be at least 2M for such objects.
> +  *
> +  * Note that due to how the hardware implements 64K GTT page support, we
> +  * have some further complications:
> +  *
> +  *   1) The entire PDE (which covers a 2MB virtual address range), must
> +  *   contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
> +  *   PDE is forbidden by the hardware.
> +  *
> +  *   2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
> +  *   objects.
> +  *
> +  * To keep things simple for userland, we mandate that any GTT mappings
> +  * must be aligned to and rounded up to 2MB.

Could I get a clarification about this "rounded up" part.

Currently Mesa is aligning the start of each and every buffer VMA to be
2MiB aligned. But, we are *not* taking any steps to "round up" the size
of buffers to 2MiB alignment.

Bob's Mesa MR from a while ago,

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14599

was trying to add this "round up" size for buffers. We didn't accept
this MR because we thought if we have ensured that no other buffer will
use the same 2MiB VMA range, then it should not be required.

If what we are doing is ok, then maybe this "round up" language should
be dropped? Or, perhaps the "round up" mentioned here isn't implying we
must align the size of buffers that we create, and I'm misinterpreting
this.

-Jordan

> As this only wastes virtual
> +  * address space and avoids userland having to copy any needlessly
> +  * complicated PDE sharing scheme (coloring) and only affects DG2, this
> +  * is deemed to be a good compromise.
>*/
>   __u64 size;
>   /**
> -- 
> 2.25.1


Re: [PATCH 00/16] DEPT(Dependency Tracker)

2022-02-17 Thread Theodore Ts'o
On Thu, Feb 17, 2022 at 12:00:05PM -0500, Steven Rostedt wrote:
> 
> I personally believe that there's potential that this can be helpful and we
> will want to merge it.
> 
> But, what I believe Ted is trying to say is, if you do not know if the
> report is a bug or not, please do not ask the maintainers to determine it
> for you. This is a good opportunity for you to look to see why your tool
> reported an issue, and learn that subsystem. Look at if this is really a
> bug or not, and investigate why.

I agree there's potential here, or I would have ignored the ext4 "bug
report".

When we can get rid of the false positives, I think it should be
merged; I'd just rather it not be merged until after the false
positives are fixed, since otherwise, someone well-meaning will start
using it with Syzkaller, and noise that maintainers need to deal with
(with people requesting reverts of two year old commits, etc) will
increase by a factor of ten or more.  (With Syzbot reproducers that
set up random cgroups, IP tunnels with wiregaurd enabled, FUSE stress
testers, etc., that file system maintainers will be asked to try to
disentangle.)

So from a maintainer's perspective, false positives are highly
negative.  It may be that from some people's POV, one bug found and 20
false positive might still be "useful".  But if your tool gains a
reputation of not valuing maintainers' time, it's just going to make
us (or at least me :-) cranky, and it's going to be very hard to
recover from perception.  So it's probably better to be very
conservative and careful in polishing it before asking for it to be
merged.

Cheers,

- Ted



Re: [Freedreno] [PATCH v2 2/2] drm/msm/dpu: Add SC8180x to hw catalog

2022-02-17 Thread Bjorn Andersson
On Thu 17 Feb 19:10 CST 2022, Dmitry Baryshkov wrote:

> On 16/02/2022 05:16, Abhinav Kumar wrote:
> > 
> > 
> > On 2/15/2022 6:03 PM, Bjorn Andersson wrote:
> > > On Tue 15 Feb 19:34 CST 2022, Abhinav Kumar wrote:
> > > 
> > > > 
> > > > 
> > > > On 2/15/2022 4:20 PM, Dmitry Baryshkov wrote:
> > > > > On Tue, 15 Feb 2022 at 23:21, Abhinav Kumar
> > > > >  wrote:
> > > > > > On 2/15/2022 10:42 AM, Dmitry Baryshkov wrote:
> > > > > > > On Tue, 15 Feb 2022 at 20:42, Abhinav Kumar
> > > > > > >  wrote:
> > > > > > > > On 2/15/2022 9:28 AM, Bjorn Andersson wrote:
> > > > > > > > > On Tue 15 Feb 11:14 CST 2022, Abhinav Kumar wrote:
> > > > > > > > > > On 2/14/2022 8:33 PM, Bjorn Andersson wrote:
> > > > > > > > > > > From: Rob Clark 
> > > [..]
> > > > > > > (thus leading us to cases when someone would forget to add 
> > > > > > > INTF_EDP
> > > > > > > next to INTF_DP)
> > > > > > > 
> > > > > > > Also, if we are switching from INTF_DP to INTF_EDP, should we stop
> > > > > > > using end-to-end numbering (like MSM_DP_CONTROLLER_2 for INTF_5) 
> > > > > > > and
> > > > > > > add a separate numbering scheme for INTF_EDP?
> > > > > > > 
> > > > > > We should change the controller ID to match what it actually is.
> > > > > > 
> > > > > > Now that you pointed this out, this looks even more confusing to me 
> > > > > > to
> > > > > > say that  MSM_DP_CONTROLLER_2 is actually a EDP controller because
> > > > > > fundamentally and even hardware block wise they are different.
> > > > > 
> > > > > So, do we split msm_priv->dp too? It's indexed using
> > > > > MSM_DP_CONTROLLER_n entries.
> > > > > Do we want to teach drm/msm/dp code that there are priv->dp[] and
> > > > > priv->edp arrays?
> > > > 
> > > > ok so now priv->dp and priv->edp arrays are also in the picture here :)
> > > > 
> > > > Actually all these questions should have probably come when we
> > > > were figuring
> > > > out how best to re-use eDP and DP driver.
> 
> Well, these questions were evaluated. And this resulted in our suggestion to
> reuse DP driver, INTF_DP type and priv->dp array.
> 
> > > > 
> > > > Either way atleast, its good we are documenting all these
> > > > questions on this
> > > > thread so that anyone can refer this to know what all was missed out :)
> > > > 
> > > > priv->dp is of type msm_dp. When re-using DP driver for eDP and since
> > > > struct msm_dp is the shared struct between dpu and the msm/dp, I
> > > > get your
> > > > point of re-using MSM_DP_CONTROLLER_* as thats being use to index.
> > > > 
> > > > So MSM_DP_CONTROLLER_* is more of an index into the DP driver
> > > > and not really
> > > > a hardware indexing scheme.
> > > > 
> > > > If we split into two arrays, we need more changes to dpu_encoder too.
> > > > 
> > > > Too instrusive a change at this point, even though probably correct.
> > > > 
> > > 
> > > I'm sorry, but performing such a split would create a whole bunch of
> > > duplication and I don't see the reasons yet. Can you please give me an
> > > example of when the DPU _code_ would benefit from being specifically
> > > written for EDP vs DP?
> > > 
> > > Things where it doesn't make sense to enable certain features in
> > > runtime - but really have different implementation for the two interface
> > > types.
> > > 
> > 
> > Like I have mentioned in my previous comment, this would be a big change
> > and I am also not in favor of this big change.
> I'm also not in favour of splitting priv->dp into ->dp and ->edp.
> 
> One of the reasons, pointed out by Bjorn, is that some of interfaces can be
> used for both DP and eDP. Adding them to either of arrays would create
> confusion.
> 
> Second reason being that introducing the split would bring in extra code for
> no additional benefits. From the DPU point of view both DP and eDP
> interfaces look the same.
> 
> > > > But are you seeing more changes required even if we just change
> > > > INTF_DP to
> > > > INTF_eDP for the eDP entries? What are the challenges there?
> > > > 
> > > 
> > > What are the benefits?
> > 
> > In terms of current code, again like I said before in my previous
> > comments several times I do not have an example.
> > 
> > I was keeping the separation in case in future for some features we do
> > need to differentiate eDP and DP.
> 
> And we also might need to separte eDP-behind msm/dp and old-8x74-eDP.
> It the same "possible" future that we might face.
> 
> > 
> > Somehow I also feel this change and below are interlinked that way.
> > 
> > https://patchwork.freedesktop.org/patch/473871/
> > 
> > The only reason we need this change is because both eDP and DP use
> > DRM_MODE_ENCODER_TMDS and specifying the intf_type directly will clear
> > the confusion because DRM_MODE_ENCODER_DSI means DSI and
> > DRM_MODE_ENCODER_VIRTUAL means Writeback but DRM_MODE_ENCODER_TMDS can
> > mean DP OR eDP interface.
> > 
> > The ambiguity was always for eDP and DP.
> > 
> > That led to the discussion about the INTF_* we are specifying in the
> > 

Re: [PATCH v6 21/23] drm: rockchip: Add VOP2 driver

2022-02-17 Thread Andy Yan

Hi Sascha:

On 2/17/22 22:06, Heiko Stübner wrote:

Am Donnerstag, 17. Februar 2022, 14:58:23 CET schrieb Sascha Hauer:

Hi Andy,

Please trim the context in your answers to the relevant parts, it makes
it easier to find the things you said.

On Thu, Feb 17, 2022 at 08:00:11PM +0800, Andy Yan wrote:

Hi Sascha:


+
+   drm_for_each_encoder_mask(encoder, crtc->dev, crtc_state->encoder_mask) 
{
+   struct rockchip_encoder *rkencoder = 
to_rockchip_encoder(encoder);
+   struct device_node *node, *parent;
+
+   parent = of_get_parent(rkencoder->port);
+
+   for_each_endpoint_of_node(parent, node) {

Is there any hurt directly use our downstream vendor kernel method here: use
vcstate->output_if set by encoder driver to get which interface we should
enable here?

There is no vcstate->output_if in mainline currently. Ok, we could add
that. The other thing is that there are multiple HDMI interfaces and
the id of the HDMI encoder is encoded into output_if. Downstream kernel
adds OF aliases to the HDMI ports. I didn't want to go that route
because it doesn't seem to be very elegant to me.
aliases is a very comm strategy in device tree world.  And your method 
also add need additional dt binds to define RK3568_VOP2_EP_xxx

You method is ok with device tree,  but it tied up this driver to device
tree, we are now tring to extend vop2 driver work with ACPI, so we hope this
driver can be much more flexible.

The current rockchip drm driver seems to be pretty much tied to device
tree. There are probably many other places that need parallel paths for
ACPI support, I think we can delay this particular part until we see the
whole picture. In the end we can still retrieve the output_if
information differently with ACPI while still retrieving the information
from the device tree the way we are doing currently.


The current driver only reference device thee at driver initial, we not 
wrap


device tree related things in other parts, so if we extend it to support 
ACPI,


we just need modify the initial code, this make things easier.


agreed :-) .

I.e. adding ACPI support for Rockchip drivers separately later on
makes things way easier.

Having a separate discussion about ACPI changes at that point
also makes the whole process easier, as adding the whole thing
here will delay everything even more.



 Heiko: I am not  ask to add new code for future  ACPI support, I just

hope the original downstream method  can keep to make future work easier.


Also if a later series really only is about adding ACPI support, this
makes for easier discussion but also easier review of changes.
The new VOP2 driver is big enough as it is.


Heiko




RE: [PATCH v2 1/3] drm/mm: Ensure that the entry is not NULL before extracting rb_node

2022-02-17 Thread Kasireddy, Vivek
Hi Tvrtko,

> 
> On 17/02/2022 07:50, Vivek Kasireddy wrote:
> > While looking for next holes suitable for an allocation, although,
> > it is highly unlikely, make sure that the DECLARE_NEXT_HOLE_ADDR
> > macro is using a valid node before it extracts the rb_node from it.
> 
> Was the need for this just a consequence of insufficient locking in the
> i915 patch?
[Kasireddy, Vivek] Partly, yes; but I figured since we are anyway doing
if (!entry || ..), it makes sense to dereference entry and extract the rb_node
after this check.

Thanks,
Vivek

> 
> Regards,
> 
> Tvrtko
> 
> >
> > Cc: Tvrtko Ursulin 
> > Cc: Christian König 
> > Signed-off-by: Vivek Kasireddy 
> > ---
> >   drivers/gpu/drm/drm_mm.c | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> > index 8257f9d4f619..499d8874e4ed 100644
> > --- a/drivers/gpu/drm/drm_mm.c
> > +++ b/drivers/gpu/drm/drm_mm.c
> > @@ -389,11 +389,12 @@ first_hole(struct drm_mm *mm,
> >   #define DECLARE_NEXT_HOLE_ADDR(name, first, last) \
> >   static struct drm_mm_node *name(struct drm_mm_node *entry, u64 size)  
> > \
> >   { \
> > -   struct rb_node *parent, *node = >rb_hole_addr;   \
> > +   struct rb_node *parent, *node;  \
> > \
> > -   if (!entry || RB_EMPTY_NODE(node))  \
> > +   if (!entry || RB_EMPTY_NODE(>rb_hole_addr))  \
> > return NULL;\
> > \
> > +   node = >rb_hole_addr;\
> > if (usable_hole_addr(node->first, size)) {  \
> > node = node->first; \
> > while (usable_hole_addr(node->last, size))  \


[PATCH] drm/amdkfd: Replace one-element array with flexible-array member

2022-02-17 Thread cgel . zte
From: Changcheng Deng 

There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use "flexible array members" for these cases. The older
style of one-element or zero-length arrays should no longer be used.
Reference:
https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays

Reported-by: Zeal Robot 
Signed-off-by: Changcheng Deng 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
index 482ba84a728d..d7c38fbc533e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.h
@@ -310,7 +310,7 @@ struct cdit_header {
uint32_tcreator_revision;
uint32_ttotal_entries;
uint16_tnum_domains;
-   uint8_t entry[1];
+   uint8_t entry[];
 };
 
 #pragma pack()
-- 
2.25.1



Re: [PATCH] drm/amdgpu: check vm bo eviction valuable at last

2022-02-17 Thread Qiang Yu
On Thu, Feb 17, 2022 at 8:22 PM Christian König
 wrote:
>
> Am 17.02.22 um 11:58 schrieb Qiang Yu:
> > On Thu, Feb 17, 2022 at 6:39 PM Christian König
> >  wrote:
> >>
> >>
> >> Am 17.02.22 um 11:13 schrieb Qiang Yu:
> >>> On Thu, Feb 17, 2022 at 5:46 PM Christian König
> >>>  wrote:
>  Am 17.02.22 um 10:40 schrieb Qiang Yu:
> > On Thu, Feb 17, 2022 at 5:15 PM Christian König
> >  wrote:
> >> Am 17.02.22 um 10:04 schrieb Qiang Yu:
> >>> Workstation application ANSA/META get this error dmesg:
> >>> [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-16)
> >>>
> >>> This is caused by:
> >>> 1. create a 256MB buffer in invisible VRAM
> >>> 2. CPU map the buffer and access it causes vm_fault and try to move
> >>>it to visible VRAM
> >>> 3. force visible VRAM space and traverse all VRAM bos to check if
> >>>evicting this bo is valuable
> >>> 4. when checking a VM bo (in invisible VRAM), amdgpu_vm_evictable()
> >>>will set amdgpu_vm->evicting, but latter due to not in visible
> >>>VRAM, won't really evict it so not add it to amdgpu_vm->evicted
> >>> 5. before next CS to clear the amdgpu_vm->evicting, user VM ops
> >>>ioctl will pass amdgpu_vm_ready() (check amdgpu_vm->evicted)
> >>>but fail in amdgpu_vm_bo_update_mapping() (check
> >>>amdgpu_vm->evicting) and get this error log
> >>>
> >>> This error won't affect functionality as next CS will finish the
> >>> waiting VM ops. But we'd better make the amdgpu_vm->evicting
> >>> correctly reflact the vm status and clear the error log.
> >> Well NAK, that is intentional behavior.
> >>
> >> The VM page tables where considered for eviction, so setting the flag 
> >> is
> >> correct even when the page tables later on are not actually evicted.
> >>
> > But this will unnecessarily stop latter user VM ops in ioctl before CS
> > even when the VM bos are not evicted.
> > Won't this have any negative effect when could do better?
>  No, this will have a positive effect. See the VM was already considered
>  for eviction because it is idle.
> 
>  Updating it immediately doesn't necessarily make sense, we should wait
>  with that until its next usage.
> 
>  Additional to that this patch doesn't really fix the problem, it just
>  mitigates it.
> 
>  Eviction can fail later on for a couple of reasons and we absolutely
>  need to check the flag instead of the list in amdgpu_vm_ready().
> >>> The flag only for both flag and list? Looks like should be both as
> >>> the list indicate some vm page table need to be updated and could
> >>> delay the user update with the same logic as you described above.
> >> I think checking the flag should be enough. The issue is that the list
> >> was there initially, but to avoid race conditions we added the flag with
> >> separate lock protection later on.
> >>
> > But list and flag does not align always, there are cases like
> > list-empty/flag-set (this problem) and list-non-empty/flag-unset (non-vm bo
> > eviction). If only check flag list-non-empty/flag-unset change behavior.
>
> Yeah, but I think that the flag unset list-non-empty case would be
> correctly handled if we only test the flag.
>
> In other words we can update the page tables as long as they are not
> partially or fully evicted and that's not the case when non-vm BOs are
> evicted.
>
This sounds like two standard for the same thing, because this problem
does not evict page tables too. But I see your point is:
There's a difference that this problem's case can make sure vm is idle,
and we prefer to delay vm updates when vm is idle.

If so, why not just stop user vm update by checking vm busy in
amdgpu_gem_va_ioctl() to skip amdgpu_gem_va_update_vm()?

Then we can keep the evicting flag accurate (after solving your
concern for this patch that eviction may fail latter by further delay
the flag update after eviction success).

Regards,
Qiang


> Regards,
> Christian.
>
> >
> > Regards,
> > Qiang
> >
> >> Regards,
> >> Christian.
> >>
> >>> Regards,
> >>> Qiang
> >>>
>  Regards,
>  Christian.
> 
> > Regards,
> > Qiang
> >
> >> What we should rather do is to fix amdgpu_vm_ready() to take a look at
> >> the flag instead of the linked list.
> >>
> >> Regards,
> >> Christian.
> >>
> >>> Signed-off-by: Qiang Yu 
> >>> ---
> >>>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 85 
> >>> ++---
> >>>  1 file changed, 47 insertions(+), 38 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> index 5a32ee66d8c8..88a27911054f 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>> @@ -1306,45 +1306,11 @@ 

Re: [Freedreno] [PATCH v2 2/2] drm/msm/dpu: Add SC8180x to hw catalog

2022-02-17 Thread Dmitry Baryshkov

On 16/02/2022 05:16, Abhinav Kumar wrote:



On 2/15/2022 6:03 PM, Bjorn Andersson wrote:

On Tue 15 Feb 19:34 CST 2022, Abhinav Kumar wrote:




On 2/15/2022 4:20 PM, Dmitry Baryshkov wrote:
On Tue, 15 Feb 2022 at 23:21, Abhinav Kumar 
 wrote:

On 2/15/2022 10:42 AM, Dmitry Baryshkov wrote:
On Tue, 15 Feb 2022 at 20:42, Abhinav Kumar 
 wrote:

On 2/15/2022 9:28 AM, Bjorn Andersson wrote:

On Tue 15 Feb 11:14 CST 2022, Abhinav Kumar wrote:

On 2/14/2022 8:33 PM, Bjorn Andersson wrote:

From: Rob Clark 

[..]

(thus leading us to cases when someone would forget to add INTF_EDP
next to INTF_DP)

Also, if we are switching from INTF_DP to INTF_EDP, should we stop
using end-to-end numbering (like MSM_DP_CONTROLLER_2 for INTF_5) and
add a separate numbering scheme for INTF_EDP?


We should change the controller ID to match what it actually is.

Now that you pointed this out, this looks even more confusing to me to
say that  MSM_DP_CONTROLLER_2 is actually a EDP controller because
fundamentally and even hardware block wise they are different.


So, do we split msm_priv->dp too? It's indexed using
MSM_DP_CONTROLLER_n entries.
Do we want to teach drm/msm/dp code that there are priv->dp[] and
priv->edp arrays?


ok so now priv->dp and priv->edp arrays are also in the picture here :)

Actually all these questions should have probably come when we were 
figuring

out how best to re-use eDP and DP driver.


Well, these questions were evaluated. And this resulted in our 
suggestion to reuse DP driver, INTF_DP type and priv->dp array.




Either way atleast, its good we are documenting all these questions 
on this

thread so that anyone can refer this to know what all was missed out :)

priv->dp is of type msm_dp. When re-using DP driver for eDP and since
struct msm_dp is the shared struct between dpu and the msm/dp, I get 
your

point of re-using MSM_DP_CONTROLLER_* as thats being use to index.

So MSM_DP_CONTROLLER_* is more of an index into the DP driver and not 
really

a hardware indexing scheme.

If we split into two arrays, we need more changes to dpu_encoder too.

Too instrusive a change at this point, even though probably correct.



I'm sorry, but performing such a split would create a whole bunch of
duplication and I don't see the reasons yet. Can you please give me an
example of when the DPU _code_ would benefit from being specifically
written for EDP vs DP?

Things where it doesn't make sense to enable certain features in
runtime - but really have different implementation for the two interface
types.



Like I have mentioned in my previous comment, this would be a big change 
and I am also not in favor of this big change.

I'm also not in favour of splitting priv->dp into ->dp and ->edp.

One of the reasons, pointed out by Bjorn, is that some of interfaces can 
be used for both DP and eDP. Adding them to either of arrays would 
create confusion.


Second reason being that introducing the split would bring in extra code 
for no additional benefits. From the DPU point of view both DP and eDP 
interfaces look the same.


But are you seeing more changes required even if we just change 
INTF_DP to

INTF_eDP for the eDP entries? What are the challenges there?



What are the benefits?


In terms of current code, again like I said before in my previous 
comments several times I do not have an example.


I was keeping the separation in case in future for some features we do 
need to differentiate eDP and DP.


And we also might need to separte eDP-behind msm/dp and old-8x74-eDP.
It the same "possible" future that we might face.



Somehow I also feel this change and below are interlinked that way.

https://patchwork.freedesktop.org/patch/473871/

The only reason we need this change is because both eDP and DP use 
DRM_MODE_ENCODER_TMDS and specifying the intf_type directly will clear 
the confusion because DRM_MODE_ENCODER_DSI means DSI and 
DRM_MODE_ENCODER_VIRTUAL means Writeback but DRM_MODE_ENCODER_TMDS can 
mean DP OR eDP interface.


The ambiguity was always for eDP and DP.

That led to the discussion about the INTF_* we are specifying in the 
dpu_hw_catalog only to find the discrepancy.


So now by clearing that ambiguity that change makes sense. That 
discussion trickled into this one.


I did some research for the INTF_*. As you probably remember (I didn't) 
on mdp4 and mdp5 chipsets we program the DISP_INTF_SEL registers, 
telling the hardware which hardware is to be driven by each of INTFs.

The freely available 410E HRD demands that this register is written.

At some point this became unnecessary, but the DPU driver kept INTF_* 
intact. Including INTF_EDP, INTF_LCDC, INTF_HDMI, etc. However from my 
understanding INTF_EDP would correspond to older eDP interfaces, not to 
eDP panels being connected by the contemporary DP/eDP ports.


Oh, and last but not least, I'd suggest to follow downstream, which uses 
"dp" to name all of DP/EDP ports. See 

Re: [PATCH v6 01/10] mm: add zone device coherent type memory support

2022-02-17 Thread Alistair Popple
Felix Kuehling  writes:

> Am 2022-02-16 um 07:26 schrieb Jason Gunthorpe:
>> The other place that needs careful audit is all the callers using
>> vm_normal_page() - they must all be able to accept a ZONE_DEVICE page
>> if we don't set pte_devmap.
>
> How much code are we talking about here? A quick search finds 26 call-sites in
> 12 files in current master:
>
>fs/proc/task_mmu.c
>mm/hmm.c
>mm/gup.c
>mm/huge_memory.c (vm_normal_page_pmd)
>mm/khugepaged.c
>mm/madvise.c
>mm/mempolicy.c
>mm/memory.c
>mm/mlock.c
>mm/migrate.c
>mm/mprotect.c
>mm/memcontrol.c
>
> I'm thinking of a more theoretical approach: Instead of auditing all users, 
> I'd
> ask, what are the invariants that a vm_normal_page should have. Then check,
> whether our DEVICE_COHERENT pages satisfy them. But maybe the concept of a
> vm_normal_page isn't defined clearly enough for that.
>
> That said, I think we (Alex and myself) made an implicit assumption from the
> start, that a DEVICE_COHERENT page should behave a lot like a normal page in
> terms of VMA mappings, even if we didn't know what that means in detail.

Yes I'm afraid I made a similar mistake when reviewing this, forgetting that
DEVICE_COHERENT pages are not LRU pages and therefore need special treatment in
some places. So for now I will have to withdraw my reviewed-by until this has
been looked at more closely, because as you note below accidentally treating
them as LRU pages leads to a bad time.

> I can now at least name some differences between DEVICE_COHERENT and normal
> pages: how the memory is allocated, how data is migrated into DEVICE_COHERENT
> pages and that it can't be on any LRU list (because the lru list_head in 
> struct
> page is aliased by pgmap and zone_device_data). Maybe I'll find more 
> differences
> if I keep digging.
>
> Regards,
>   Felix
>
>
>>
>> Jason


Re: [PATCH v4 2/5] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

2022-02-17 Thread Doug Anderson
Hi,

On Thu, Feb 10, 2022 at 3:58 AM Sankeerth Billakanti
 wrote:
>
> +   backlight_3v3_regulator: backlight-3v3-regulator {
> +   compatible = "regulator-fixed";
> +   regulator-name = "backlight_3v3_regulator";
> +
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +
> +   gpio = <_gpios 7 GPIO_ACTIVE_HIGH>;
> +   enable-active-high;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_bl_power>;
> +   };

So I'm pretty sure that this is wrong and what you had on a previous
patch was more correct. Specifically the PMIC's GPIO 7 truly _is_ an
enable pin for the backlight. In the schematics I see it's named as
"PMIC_EDP_BL_EN" and is essentially the same net as "EDP_BL_EN". This
is distinct from the backlight _regulator_ that is named VREG_EDP_BP.
I believe the VREG_EDP_BP is essentially sourced directly from
PPVAR_SYS. That's how it works on herobrine and I believe that CRD is
the same. You currently don't model ppvar_sys, but it's basically just
a variable-voltage rail that could be provided somewhat directly from
the battery or could be provided from Type C components. I believe
that the panel backlight is designed to handle this fairly wide
voltage range and it's done this way to get the best efficiency.

So personally I'd prefer if you do something like herobrine and model
PPVAR_SYS. Then the backlight can use ppvar_sys as its regulator and
you can go back to providing this as an "enable" pin for the
backlight.

I know, technically it doesn't _really_ matter, but it's nice to model
it more correctly.


[PATCH V2 04/11] drm/bridge: tc358767: Implement atomic_check callback

2022-02-17 Thread Marek Vasut
Implement .atomic_check callback which prevents user space from setting
unsupported mode. The tc_edp_common_atomic_check() variant is already
prepared for DSI-to-DPI mode addition, which has different frequency
limits.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - New patch
---
 drivers/gpu/drm/bridge/tc358767.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 522c2c4d8514f..01d11adee6c74 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1289,6 +1289,31 @@ static bool tc_bridge_mode_fixup(struct drm_bridge 
*bridge,
return true;
 }
 
+static int tc_edp_common_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state,
+ const unsigned int max_khz)
+{
+   tc_bridge_mode_fixup(bridge, _state->mode,
+_state->adjusted_mode);
+
+   if (crtc_state->adjusted_mode.clock > max_khz)
+   crtc_state->adjusted_mode.clock = max_khz;
+
+   return 0;
+}
+
+static int tc_edp_atomic_check(struct drm_bridge *bridge,
+  struct drm_bridge_state *bridge_state,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state)
+{
+   /* DPI->(e)DP interface clock limitation: upto 154 MHz */
+   return tc_edp_common_atomic_check(bridge, bridge_state, crtc_state,
+ conn_state, 154000);
+}
+
 static enum drm_mode_status
 tc_edp_mode_valid(struct drm_bridge *bridge,
  const struct drm_display_info *info,
@@ -1463,6 +1488,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.detach = tc_edp_bridge_detach,
.mode_valid = tc_edp_mode_valid,
.mode_set = tc_bridge_mode_set,
+   .atomic_check = tc_edp_atomic_check,
.atomic_enable = tc_edp_bridge_atomic_enable,
.atomic_disable = tc_edp_bridge_atomic_disable,
.mode_fixup = tc_bridge_mode_fixup,
-- 
2.34.1



[PATCH V2 10/11] drm/bridge: tc358767: Split tc_set_video_mode() into common and (e)DP part

2022-02-17 Thread Marek Vasut
The tc_set_video_mode() sets up both common and (e)DP video mode settings of
the bridge chip. Split the function into tc_set_common_video_mode() to set
the common settings and tc_set_edp_video_mode() to set the (e)DP specific
settings. No functional change.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - New patch
---
 drivers/gpu/drm/bridge/tc358767.c | 48 ---
 1 file changed, 37 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 4af0ad5db2148..091c969a36ab7 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -734,11 +734,10 @@ static int tc_get_display_props(struct tc_data *tc)
return ret;
 }
 
-static int tc_set_video_mode(struct tc_data *tc,
-const struct drm_display_mode *mode)
+static int tc_set_common_video_mode(struct tc_data *tc,
+   const struct drm_display_mode *mode)
 {
int ret;
-   int vid_sync_dly;
int max_tu_symbol;
 
int left_margin = mode->htotal - mode->hsync_end;
@@ -747,7 +746,6 @@ static int tc_set_video_mode(struct tc_data *tc,
int upper_margin = mode->vtotal - mode->vsync_end;
int lower_margin = mode->vsync_start - mode->vdisplay;
int vsync_len = mode->vsync_end - mode->vsync_start;
-   u32 dp0_syncval;
u32 bits_per_pixel = 24;
u32 in_bw, out_bw;
 
@@ -818,8 +816,35 @@ static int tc_set_video_mode(struct tc_data *tc,
   FIELD_PREP(COLOR_B, 99) |
   ENI2CFILTER |
   FIELD_PREP(COLOR_BAR_MODE, COLOR_BAR_MODE_BARS));
-   if (ret)
-   return ret;
+
+   return ret;
+}
+
+static int tc_set_edp_video_mode(struct tc_data *tc,
+const struct drm_display_mode *mode)
+{
+   int ret;
+   int vid_sync_dly;
+   int max_tu_symbol;
+
+   int left_margin = mode->htotal - mode->hsync_end;
+   int hsync_len = mode->hsync_end - mode->hsync_start;
+   int upper_margin = mode->vtotal - mode->vsync_end;
+   int vsync_len = mode->vsync_end - mode->vsync_start;
+   u32 dp0_syncval;
+   u32 bits_per_pixel = 24;
+   u32 in_bw, out_bw;
+
+   /*
+* Recommended maximum number of symbols transferred in a transfer unit:
+* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
+*  (output active video bandwidth in bytes))
+* Must be less than tu_size.
+*/
+
+   in_bw = mode->clock * bits_per_pixel / 8;
+   out_bw = tc->link.num_lanes * tc->link.rate;
+   max_tu_symbol = DIV_ROUND_UP(in_bw * TU_SIZE_RECOMMENDED, out_bw);
 
/* DP Main Stream Attributes */
vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
@@ -869,10 +894,7 @@ static int tc_set_video_mode(struct tc_data *tc,
   FIELD_PREP(MAX_TU_SYMBOL, max_tu_symbol) |
   FIELD_PREP(TU_SIZE, TU_SIZE_RECOMMENDED) |
   BPC_8);
-   if (ret)
-   return ret;
-
-   return 0;
+   return ret;
 }
 
 static int tc_wait_link_training(struct tc_data *tc)
@@ -1185,7 +1207,11 @@ static int tc_edp_stream_enable(struct tc_data *tc)
return ret;
}
 
-   ret = tc_set_video_mode(tc, >mode);
+   ret = tc_set_common_video_mode(tc, >mode);
+   if (ret)
+   return ret;
+
+   ret = tc_set_edp_video_mode(tc, >mode);
if (ret)
return ret;
 
-- 
2.34.1



[PATCH V2 09/11] drm/bridge: tc358767: Detect bridge mode from connected endpoints in DT

2022-02-17 Thread Marek Vasut
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. It is possible to find out the mode in which the
bridge should be operated by testing connected endpoints in DT.

Port allocation:
port@0 - DSI input
port@1 - DPI input/output
port@2 - eDP output

Possible connections:
DPI -> port@1 -> port@2 -> eDP :: [port@0 is not connected]
DSI -> port@0 -> port@2 -> eDP :: [port@1 is not connected]
DSI -> port@0 -> port@1 -> DPI :: [port@2 is not connected]

Add function to determine the bridge mode based on connected endpoints.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - New patch
---
 drivers/gpu/drm/bridge/tc358767.c | 46 ++-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 7dae18de76c97..4af0ad5db2148 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1684,6 +1684,50 @@ static int tc_probe_edp_bridge_endpoint(struct tc_data 
*tc)
return ret;
 }
 
+static int tc_probe_bridge_endpoint(struct tc_data *tc)
+{
+   struct device *dev = tc->dev;
+   struct of_endpoint endpoint;
+   struct device_node *node = NULL;
+   const u8 mode_dpi_to_edp = BIT(1) | BIT(2);
+   const u8 mode_dsi_to_edp = BIT(0) | BIT(2);
+   const u8 mode_dsi_to_dpi = BIT(0) | BIT(1);
+   u8 mode = 0;
+
+   /*
+* Determine bridge configuration.
+*
+* Port allocation:
+* port@0 - DSI input
+* port@1 - DPI input/output
+* port@2 - eDP output
+*
+* Possible connections:
+* DPI -> port@1 -> port@2 -> eDP :: [port@0 is not connected]
+* DSI -> port@0 -> port@2 -> eDP :: [port@1 is not connected]
+* DSI -> port@0 -> port@1 -> DPI :: [port@2 is not connected]
+*/
+
+   for_each_endpoint_of_node(dev->of_node, node) {
+   of_graph_parse_endpoint(node, );
+   if (endpoint.port > 2)
+   return -EINVAL;
+
+   mode |= BIT(endpoint.port);
+   }
+
+   if (mode == mode_dpi_to_edp)
+   return tc_probe_edp_bridge_endpoint(tc);
+   else if (mode == mode_dsi_to_dpi)
+   dev_warn(dev, "The mode DSI-to-DPI is not supported!\n");
+   else if (mode == mode_dsi_to_edp)
+   dev_warn(dev, "The mode DSI-to-(e)DP is not supported!\n");
+   else
+   dev_warn(dev, "Invalid mode (0x%x) is not supported!\n", mode);
+
+   return -EINVAL;
+}
+
 static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
 {
struct device *dev = >dev;
@@ -1696,7 +1740,7 @@ static int tc_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
tc->dev = dev;
 
-   ret = tc_probe_edp_bridge_endpoint(tc);
+   ret = tc_probe_bridge_endpoint(tc);
if (ret)
return ret;
 
-- 
2.34.1



[PATCH V2 08/11] drm/bridge: tc358767: Move bridge ops setup into tc_probe_edp_bridge_endpoint()

2022-02-17 Thread Marek Vasut
The bridge ops are specific to the bridge configuration, move them
into tc_probe_edp_bridge_endpoint() to permit cleaner addition of
DSI-to-DPI mode. No functional change.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - New patch
---
 drivers/gpu/drm/bridge/tc358767.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 55b7f3fb9eec9..7dae18de76c97 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1676,6 +1676,11 @@ static int tc_probe_edp_bridge_endpoint(struct tc_data 
*tc)
tc->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
}
 
+   tc->bridge.funcs = _bridge_funcs;
+   if (tc->hpd_pin >= 0)
+   tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
+   tc->bridge.ops |= DRM_BRIDGE_OP_EDID;
+
return ret;
 }
 
@@ -1757,11 +1762,6 @@ static int tc_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
if (ret)
return ret;
 
-   tc->bridge.funcs = _bridge_funcs;
-   if (tc->hpd_pin >= 0)
-   tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
-   tc->bridge.ops |= DRM_BRIDGE_OP_EDID;
-
tc->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
 
-- 
2.34.1



[PATCH V2 07/11] drm/bridge: tc358767: Wrap (e)DP aux I2C registration into tc_aux_link_setup()

2022-02-17 Thread Marek Vasut
This bit of code is (e)DP and aux I2C link specific, move it into
tc_aux_link_setup() to permit cleaner addition of DSI-to-DPI mode.
No functional change.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - New patch
---
 drivers/gpu/drm/bridge/tc358767.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 450a472888ba9..55b7f3fb9eec9 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -656,6 +656,12 @@ static int tc_aux_link_setup(struct tc_data *tc)
if (ret)
goto err;
 
+   /* Register DP AUX channel */
+   tc->aux.name = "TC358767 AUX i2c adapter";
+   tc->aux.dev = tc->dev;
+   tc->aux.transfer = tc_aux_transfer;
+   drm_dp_aux_init(>aux);
+
return 0;
 err:
dev_err(tc->dev, "tc_aux_link_setup failed: %d\n", ret);
@@ -1751,12 +1757,6 @@ static int tc_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
if (ret)
return ret;
 
-   /* Register DP AUX channel */
-   tc->aux.name = "TC358767 AUX i2c adapter";
-   tc->aux.dev = tc->dev;
-   tc->aux.transfer = tc_aux_transfer;
-   drm_dp_aux_init(>aux);
-
tc->bridge.funcs = _bridge_funcs;
if (tc->hpd_pin >= 0)
tc->bridge.ops |= DRM_BRIDGE_OP_DETECT;
-- 
2.34.1



[PATCH V2 05/11] drm/bridge: tc358767: Move hardware init to enable callback

2022-02-17 Thread Marek Vasut
The TC358767/TC358867/TC9595 are all capable of operating either from
attached Xtal or from DSI clock lane clock. In case the later is used,
all I2C accesses will fail until the DSI clock lane is running and
supplying clock to the chip.

Move all hardware initialization to enable callback to guarantee the
DSI clock lane is running before accessing the hardware. In case Xtal
is attached to the chip, this change has no effect.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - Rebase on next-20220217
---
 drivers/gpu/drm/bridge/tc358767.c | 111 +-
 1 file changed, 63 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 01d11adee6c74..134c4d8621236 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1234,6 +1234,63 @@ static int tc_edp_stream_disable(struct tc_data *tc)
return 0;
 }
 
+static int tc_hardware_init(struct tc_data *tc)
+{
+   int ret;
+
+   ret = regmap_read(tc->regmap, TC_IDREG, >rev);
+   if (ret) {
+   dev_err(tc->dev, "can not read device ID: %d\n", ret);
+   return ret;
+   }
+
+   if ((tc->rev != 0x6601) && (tc->rev != 0x6603)) {
+   dev_err(tc->dev, "invalid device ID: 0x%08x\n", tc->rev);
+   return -EINVAL;
+   }
+
+   tc->assr = (tc->rev == 0x6601); /* Enable ASSR for eDP panels */
+
+   if (!tc->reset_gpio) {
+   /*
+* If the reset pin isn't present, do a software reset. It isn't
+* as thorough as the hardware reset, as we can't reset the I2C
+* communication block for obvious reasons, but it's getting the
+* chip into a defined state.
+*/
+   regmap_update_bits(tc->regmap, SYSRSTENB,
+   ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP,
+   0);
+   regmap_update_bits(tc->regmap, SYSRSTENB,
+   ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP,
+   ENBLCD0 | ENBBM | ENBDSIRX | ENBREG | ENBHDCP);
+   usleep_range(5000, 1);
+   }
+
+   if (tc->hpd_pin >= 0) {
+   u32 lcnt_reg = tc->hpd_pin == 0 ? INT_GP0_LCNT : INT_GP1_LCNT;
+   u32 h_lc = INT_GPIO_H(tc->hpd_pin) | INT_GPIO_LC(tc->hpd_pin);
+
+   /* Set LCNT to 2ms */
+   regmap_write(tc->regmap, lcnt_reg,
+clk_get_rate(tc->refclk) * 2 / 1000);
+   /* We need the "alternate" mode for HPD */
+   regmap_write(tc->regmap, GPIOM, BIT(tc->hpd_pin));
+
+   if (tc->have_irq) {
+   /* enable H & LC */
+   regmap_update_bits(tc->regmap, INTCTL_G, h_lc, h_lc);
+   }
+   }
+
+   if (tc->have_irq) {
+   /* enable SysErr */
+   regmap_write(tc->regmap, INTCTL_G, INT_SYSERR);
+   }
+
+   return 0;
+}
+
 static void
 tc_edp_bridge_atomic_enable(struct drm_bridge *bridge,
struct drm_bridge_state *old_bridge_state)
@@ -1241,6 +1298,12 @@ tc_edp_bridge_atomic_enable(struct drm_bridge *bridge,
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
 
+   ret = tc_hardware_init(tc);
+   if (ret < 0) {
+   dev_err(tc->dev, "failed to initialize bridge: %d\n", ret);
+   return;
+   }
+
ret = tc_get_display_props(tc);
if (ret < 0) {
dev_err(tc->dev, "failed to read display props: %d\n", ret);
@@ -1660,9 +1723,6 @@ static int tc_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
}
 
if (client->irq > 0) {
-   /* enable SysErr */
-   regmap_write(tc->regmap, INTCTL_G, INT_SYSERR);
-
ret = devm_request_threaded_irq(dev, client->irq,
NULL, tc_irq_handler,
IRQF_ONESHOT,
@@ -1675,51 +1735,6 @@ static int tc_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
tc->have_irq = true;
}
 
-   ret = regmap_read(tc->regmap, TC_IDREG, >rev);
-   if (ret) {
-   dev_err(tc->dev, "can not read device ID: %d\n", ret);
-   return ret;
-   }
-
-   if ((tc->rev != 0x6601) && (tc->rev != 0x6603)) {
-   dev_err(tc->dev, "invalid device ID: 0x%08x\n", tc->rev);
-   return -EINVAL;
-   }
-
-   tc->assr = (tc->rev == 0x6601); /* Enable ASSR for

[PATCH V2 11/11] drm/bridge: tc358767: Add DSI-to-DPI mode support

2022-02-17 Thread Marek Vasut
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Add support for the
DSI-to-DPI mode.

This requires skipping most of the (e)DP initialization code, which is
currently a large part of this driver, hence it is better to have far
simpler separate tc_dpi_bridge_funcs and their implementation.

The configuration of DPI output is also much simpler. The configuration
of the DSI input is rather similar to the other TC bridge chips.

The Pixel PLL in DPI output mode does not have the 65..150 MHz limitation
imposed on the (e)DP output mode, so this limitation is skipped to permit
operating panels with far slower pixel clock, even below 9 MHz. This mode
of operation of the PLL is valid and tested.

The detection of bridge mode is now added into tc_probe_bridge_mode(),
where in case a DPI panel is found on port@1 endpoint@1, the mode is
assumed to be DSI-to-DPI. If (e)DP is detected on port@2, the mode is
assumed to be DPI-to-(e)DP.

The DSI-to-(e)DP mode is not supported due to lack of proper hardware,
but this would be some sort of mix between the two aforementioned modes.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - Rebase on next-20220217 and new patches in this series
---
 drivers/gpu/drm/bridge/tc358767.c | 339 +-
 1 file changed, 332 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 091c969a36ab7..2b9fceb1333fa 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1,6 +1,12 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 /*
- * tc358767 eDP bridge driver
+ * TC358767/TC358867/TC9595 DSI/DPI-to-DPI/(e)DP bridge driver
+ *
+ * The TC358767/TC358867/TC9595 can operate in multiple modes.
+ * The following modes are supported:
+ *   DPI->(e)DP -- supported
+ *   DSI->DPI  supported
+ *   DSI->(e)DP .. NOT supported
  *
  * Copyright (C) 2016 CogentEmbedded Inc
  * Author: Andrey Gusakov 
@@ -29,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -36,7 +43,35 @@
 
 /* Registers */
 
-/* Display Parallel Interface */
+/* PPI layer registers */
+#define PPI_STARTPPI   0x0104 /* START control bit */
+#define PPI_LPTXTIMECNT0x0114 /* LPTX timing signal */
+#define LPX_PERIOD 3
+#define PPI_LANEENABLE 0x0134
+#define PPI_TX_RX_TA   0x013c
+#define TTA_GET0x4
+#define TTA_SURE   6
+#define PPI_D0S_ATMR   0x0144
+#define PPI_D1S_ATMR   0x0148
+#define PPI_D0S_CLRSIPOCOUNT   0x0164 /* Assertion timer for Lane 0 */
+#define PPI_D1S_CLRSIPOCOUNT   0x0168 /* Assertion timer for Lane 1 */
+#define PPI_D2S_CLRSIPOCOUNT   0x016c /* Assertion timer for Lane 2 */
+#define PPI_D3S_CLRSIPOCOUNT   0x0170 /* Assertion timer for Lane 3 */
+#define PPI_START_FUNCTION BIT(0)
+
+/* DSI layer registers */
+#define DSI_STARTDSI   0x0204 /* START control bit of DSI-TX */
+#define DSI_LANEENABLE 0x0210 /* Enables each lane */
+#define DSI_RX_START   BIT(0)
+
+/* Lane enable PPI and DSI register bits */
+#define LANEENABLE_CLENBIT(0)
+#define LANEENABLE_L0ENBIT(1)
+#define LANEENABLE_L1ENBIT(2)
+#define LANEENABLE_L2ENBIT(1)
+#define LANEENABLE_L3ENBIT(2)
+
+/* Display Parallel Input Interface */
 #define DPIPXLFMT  0x0440
 #define VS_POL_ACTIVE_LOW  (1 << 10)
 #define HS_POL_ACTIVE_LOW  (1 << 9)
@@ -48,6 +83,14 @@
 #define DPI_BPP_RGB666 (1 << 0)
 #define DPI_BPP_RGB565 (2 << 0)
 
+/* Display Parallel Output Interface */
+#define POCTRL 0x0448
+#define POCTRL_S2P BIT(7)
+#define POCTRL_PCLK_POLBIT(3)
+#define POCTRL_VS_POL  BIT(2)
+#define POCTRL_HS_POL  BIT(1)
+#define POCTRL_DE_POL  BIT(0)
+
 /* Video Path */
 #define VPCTRL00x0450
 #define VSDELAYGENMASK(31, 20)
@@ -247,6 +290,9 @@ struct tc_data {
struct drm_bridge   *panel_bridge;
struct drm_connectorconnector;
 
+   struct mipi_dsi_device  *dsi;
+   u8  dsi_lanes;
+
/* link settings */
struct tc_edp_link  link;
 
@@ -502,8 +548,10 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, 
u32 pixelclock)
/*
 * refclk * mul / (ext_pre_div * pre_div)
 * should be in the 150 to 650 MHz range
+* for (e)DP
 */
-  

[PATCH V2 06/11] drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into dedicated function

2022-02-17 Thread Marek Vasut
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. In order to support the rest of the modes without
making the tc_probe() overly long, split the bridge endpoint parsing
into dedicated function, where the necessary logic to detect the bridge
mode based on which endpoints are connected, can be implemented.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - Rename tc_probe_bridge_mode() to tc_probe_edp_bridge_endpoint()
  to better reflect that it parses the (e)DP output endpoint
---
 drivers/gpu/drm/bridge/tc358767.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 134c4d8621236..450a472888ba9 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1646,19 +1646,12 @@ static irqreturn_t tc_irq_handler(int irq, void *arg)
return IRQ_HANDLED;
 }
 
-static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
+static int tc_probe_edp_bridge_endpoint(struct tc_data *tc)
 {
-   struct device *dev = >dev;
+   struct device *dev = tc->dev;
struct drm_panel *panel;
-   struct tc_data *tc;
int ret;
 
-   tc = devm_kzalloc(dev, sizeof(*tc), GFP_KERNEL);
-   if (!tc)
-   return -ENOMEM;
-
-   tc->dev = dev;
-
/* port@2 is the output port */
ret = drm_of_find_panel_or_bridge(dev->of_node, 2, 0, , NULL);
if (ret && ret != -ENODEV)
@@ -1677,6 +1670,25 @@ static int tc_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
tc->bridge.type = DRM_MODE_CONNECTOR_DisplayPort;
}
 
+   return ret;
+}
+
+static int tc_probe(struct i2c_client *client, const struct i2c_device_id *id)
+{
+   struct device *dev = >dev;
+   struct tc_data *tc;
+   int ret;
+
+   tc = devm_kzalloc(dev, sizeof(*tc), GFP_KERNEL);
+   if (!tc)
+   return -ENOMEM;
+
+   tc->dev = dev;
+
+   ret = tc_probe_edp_bridge_endpoint(tc);
+   if (ret)
+   return ret;
+
/* Shut down GPIO is optional */
tc->sd_gpio = devm_gpiod_get_optional(dev, "shutdown", GPIOD_OUT_HIGH);
if (IS_ERR(tc->sd_gpio))
-- 
2.34.1



[PATCH V2 02/11] drm/bridge: tc358767: Change tc_ prefix to tc_edp_ for (e)DP specific functions

2022-02-17 Thread Marek Vasut
These functions are specific to (e)DP output initialization and
operation, add specific tc_edp_ prefix to those functions to
discern them from DPI output functions that will be added later
in this series. No functional change.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - New patch
---
 drivers/gpu/drm/bridge/tc358767.c | 35 ---
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index c23e0abc65e8f..4b8ea0db2a5e8 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1164,7 +1164,7 @@ static int tc_main_link_disable(struct tc_data *tc)
return regmap_write(tc->regmap, DP0CTL, 0);
 }
 
-static int tc_stream_enable(struct tc_data *tc)
+static int tc_edp_stream_enable(struct tc_data *tc)
 {
int ret;
u32 value;
@@ -1219,7 +1219,7 @@ static int tc_stream_enable(struct tc_data *tc)
return 0;
 }
 
-static int tc_stream_disable(struct tc_data *tc)
+static int tc_edp_stream_disable(struct tc_data *tc)
 {
int ret;
 
@@ -1234,7 +1234,7 @@ static int tc_stream_disable(struct tc_data *tc)
return 0;
 }
 
-static void tc_bridge_enable(struct drm_bridge *bridge)
+static void tc_edp_bridge_enable(struct drm_bridge *bridge)
 {
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
@@ -1251,7 +1251,7 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
return;
}
 
-   ret = tc_stream_enable(tc);
+   ret = tc_edp_stream_enable(tc);
if (ret < 0) {
dev_err(tc->dev, "main link stream start error: %d\n", ret);
tc_main_link_disable(tc);
@@ -1259,12 +1259,12 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
}
 }
 
-static void tc_bridge_disable(struct drm_bridge *bridge)
+static void tc_edp_bridge_disable(struct drm_bridge *bridge)
 {
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
 
-   ret = tc_stream_disable(tc);
+   ret = tc_edp_stream_disable(tc);
if (ret < 0)
dev_err(tc->dev, "main link stream stop error: %d\n", ret);
 
@@ -1285,9 +1285,10 @@ static bool tc_bridge_mode_fixup(struct drm_bridge 
*bridge,
return true;
 }
 
-static enum drm_mode_status tc_mode_valid(struct drm_bridge *bridge,
- const struct drm_display_info *info,
- const struct drm_display_mode *mode)
+static enum drm_mode_status
+tc_edp_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
 {
struct tc_data *tc = bridge_to_tc(bridge);
u32 req, avail;
@@ -1395,8 +1396,8 @@ static const struct drm_connector_funcs 
tc_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
-static int tc_bridge_attach(struct drm_bridge *bridge,
-   enum drm_bridge_attach_flags flags)
+static int tc_edp_bridge_attach(struct drm_bridge *bridge,
+   enum drm_bridge_attach_flags flags)
 {
u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
struct tc_data *tc = bridge_to_tc(bridge);
@@ -1448,18 +1449,18 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
return ret;
 }
 
-static void tc_bridge_detach(struct drm_bridge *bridge)
+static void tc_edp_bridge_detach(struct drm_bridge *bridge)
 {
drm_dp_aux_unregister(_to_tc(bridge)->aux);
 }
 
 static const struct drm_bridge_funcs tc_bridge_funcs = {
-   .attach = tc_bridge_attach,
-   .detach = tc_bridge_detach,
-   .mode_valid = tc_mode_valid,
+   .attach = tc_edp_bridge_attach,
+   .detach = tc_edp_bridge_detach,
+   .mode_valid = tc_edp_mode_valid,
.mode_set = tc_bridge_mode_set,
-   .enable = tc_bridge_enable,
-   .disable = tc_bridge_disable,
+   .enable = tc_edp_bridge_enable,
+   .disable = tc_edp_bridge_disable,
.mode_fixup = tc_bridge_mode_fixup,
.detect = tc_bridge_detect,
.get_edid = tc_get_edid,
-- 
2.34.1



[PATCH V2 03/11] drm/bridge: tc358767: Convert to atomic ops

2022-02-17 Thread Marek Vasut
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API. This will be needed to access the mode
from the atomic state.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
---
V2: - New patch
---
 drivers/gpu/drm/bridge/tc358767.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 4b8ea0db2a5e8..522c2c4d8514f 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1234,7 +1234,9 @@ static int tc_edp_stream_disable(struct tc_data *tc)
return 0;
 }
 
-static void tc_edp_bridge_enable(struct drm_bridge *bridge)
+static void
+tc_edp_bridge_atomic_enable(struct drm_bridge *bridge,
+   struct drm_bridge_state *old_bridge_state)
 {
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
@@ -1259,7 +1261,9 @@ static void tc_edp_bridge_enable(struct drm_bridge 
*bridge)
}
 }
 
-static void tc_edp_bridge_disable(struct drm_bridge *bridge)
+static void
+tc_edp_bridge_atomic_disable(struct drm_bridge *bridge,
+struct drm_bridge_state *old_bridge_state)
 {
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
@@ -1459,11 +1463,14 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.detach = tc_edp_bridge_detach,
.mode_valid = tc_edp_mode_valid,
.mode_set = tc_bridge_mode_set,
-   .enable = tc_edp_bridge_enable,
-   .disable = tc_edp_bridge_disable,
+   .atomic_enable = tc_edp_bridge_atomic_enable,
+   .atomic_disable = tc_edp_bridge_atomic_disable,
.mode_fixup = tc_bridge_mode_fixup,
.detect = tc_bridge_detect,
.get_edid = tc_get_edid,
+   .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,
 };
 
 static bool tc_readable_reg(struct device *dev, unsigned int reg)
-- 
2.34.1



[PATCH V2 01/11] dt-bindings: display: bridge: tc358867: Document DPI output support

2022-02-17 Thread Marek Vasut
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Document support for the
DPI output port, which can now be connected both as input and output.

Signed-off-by: Marek Vasut 
Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Rob Herring 
Cc: Sam Ravnborg 
Cc: devicet...@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
V2: - Rebase on next-20220217
---
 .../devicetree/bindings/display/bridge/toshiba,tc358767.yaml  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
index f1541cc052977..5cfda6f2ba69c 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
@@ -61,8 +61,8 @@ properties:
   port@1:
 $ref: /schemas/graph.yaml#/properties/port
 description: |
-DPI input port. The remote endpoint phandle should be a
-reference to a valid DPI output endpoint node
+DPI input/output port. The remote endpoint phandle should be a
+reference to a valid DPI output or input endpoint node.
 
   port@2:
 $ref: /schemas/graph.yaml#/properties/port
-- 
2.34.1



[PATCH V2 00/11] drm/bridge: tc358767: Add DSI-to-DPI mode support

2022-02-17 Thread Marek Vasut
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Clean up the driver,
switch to atomic ops, and add support for the DSI-to-DPI mode in
addition to already supported DPI-to-(e)DP mode.

Cc: Jonas Karlman 
Cc: Laurent Pinchart 
Cc: Maxime Ripard 
Cc: Neil Armstrong 
Cc: Sam Ravnborg 
To: dri-devel@lists.freedesktop.org

Marek Vasut (11):
  dt-bindings: display: bridge: tc358867: Document DPI output support
  drm/bridge: tc358767: Change tc_ prefix to tc_edp_ for (e)DP specific
functions
  drm/bridge: tc358767: Convert to atomic ops
  drm/bridge: tc358767: Implement atomic_check callback
  drm/bridge: tc358767: Move hardware init to enable callback
  drm/bridge: tc358767: Move (e)DP bridge endpoint parsing into
dedicated function
  drm/bridge: tc358767: Wrap (e)DP aux I2C registration into
tc_aux_link_setup()
  drm/bridge: tc358767: Move bridge ops setup into
tc_probe_edp_bridge_endpoint()
  drm/bridge: tc358767: Detect bridge mode from connected endpoints in
DT
  drm/bridge: tc358767: Split tc_set_video_mode() into common and (e)DP
part
  drm/bridge: tc358767: Add DSI-to-DPI mode support

 .../display/bridge/toshiba,tc358767.yaml  |   4 +-
 drivers/gpu/drm/bridge/tc358767.c | 654 +++---
 2 files changed, 557 insertions(+), 101 deletions(-)

-- 
2.34.1



Re: [PATCH v6 01/10] mm: add zone device coherent type memory support

2022-02-17 Thread Jason Gunthorpe
On Thu, Feb 17, 2022 at 04:12:20PM -0500, Felix Kuehling wrote:

> I'm thinking of a more theoretical approach: Instead of auditing all users,
> I'd ask, what are the invariants that a vm_normal_page should have. Then
> check, whether our DEVICE_COHERENT pages satisfy them. But maybe the concept
> of a vm_normal_page isn't defined clearly enough for that.

I would say the expectation is that only 'page cache and anon' pages
are returned - ie the first union in struct page

This is because the first file in your list I looked at:

static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
unsigned long addr, unsigned long end,
struct mm_walk *walk)

{
page = vm_normal_page(vma, addr, ptent);
[..]
if (pageout) {
if (!isolate_lru_page(page)) {

Uses the LRU field, so this is incompatible with all the other page
types.

One mitigation of this might be to formally make vm_normal_page() ==
'pte to page cache and anon page' and add a new function that is 'pte
to any struct page'

Then go through and sort callers as appropriate.

The 'pte to page cache and anon page' can detect ZONE_DEVICE by
calling is_zone_device_page() insted of pte_devmap() and then continue
to return NULL. This same trick will fix GUP_fast.

Jason



Re: [PATCH v2 2/2] drm/msm/dpu: Add SC8180x to hw catalog

2022-02-17 Thread Dmitry Baryshkov

On 16/02/2022 04:34, Abhinav Kumar wrote:



On 2/15/2022 4:20 PM, Dmitry Baryshkov wrote:
On Tue, 15 Feb 2022 at 23:21, Abhinav Kumar 
 wrote:

On 2/15/2022 10:42 AM, Dmitry Baryshkov wrote:
On Tue, 15 Feb 2022 at 20:42, Abhinav Kumar 
 wrote:

On 2/15/2022 9:28 AM, Bjorn Andersson wrote:

On Tue 15 Feb 11:14 CST 2022, Abhinav Kumar wrote:




On 2/14/2022 8:33 PM, Bjorn Andersson wrote:

From: Rob Clark 

Add SC8180x to the hardware catalog, for initial support for the
platform. Due to limitations in the DP driver only one of the 
four DP

interfaces is left enabled.

The SC8180x platform supports the newly added DPU_INTF_WIDEBUS 
flag and
the Windows-on-Snapdragon bootloader leaves the widebus bit set, 
so this

is flagged appropriately to ensure widebus is disabled - for now.

Signed-off-by: Rob Clark 
[bjorn: Reworked intf and irq definitions]
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Dropped widebus flag

 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c    | 129 
++

 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h    |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   1 +
 drivers/gpu/drm/msm/msm_drv.c |   1 +
 4 files changed, 132 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c

index aa75991903a6..7ac0fe32df49 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -90,6 +90,17 @@
   BIT(MDP_INTF3_INTR) | \
   BIT(MDP_INTF4_INTR))
+#define IRQ_SC8180X_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
+ BIT(MDP_SSPP_TOP0_INTR2) | \
+ BIT(MDP_SSPP_TOP0_HIST_INTR) | \
+ BIT(MDP_INTF0_INTR) | \
+ BIT(MDP_INTF1_INTR) | \
+ BIT(MDP_INTF2_INTR) | \
+ BIT(MDP_INTF3_INTR) | \
+ BIT(MDP_INTF4_INTR) | \
+ BIT(MDP_INTF5_INTR) | \
+ BIT(MDP_AD4_0_INTR) | \
+ BIT(MDP_AD4_1_INTR))
 #define DEFAULT_PIXEL_RAM_SIZE   (50 * 1024)
 #define DEFAULT_DPU_LINE_WIDTH   2048
@@ -225,6 +236,22 @@ static const struct dpu_caps 
sm8150_dpu_caps = {

  .max_vdeci_exp = MAX_VERT_DECIMATION,
 };
+static const struct dpu_caps sc8180x_dpu_caps = {
+   .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+   .max_mixer_blendstages = 0xb,
+   .qseed_type = DPU_SSPP_SCALER_QSEED3,
+   .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
+   .ubwc_version = DPU_HW_UBWC_VER_30,
+   .has_src_split = true,
+   .has_dim_layer = true,
+   .has_idle_pc = true,
+   .has_3d_merge = true,
+   .max_linewidth = 4096,
+   .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+   .max_hdeci_exp = MAX_HORZ_DECIMATION,
+   .max_vdeci_exp = MAX_VERT_DECIMATION,
+};
+
 static const struct dpu_caps sm8250_dpu_caps = {
  .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
  .max_mixer_blendstages = 0xb,
@@ -293,6 +320,31 @@ static const struct dpu_mdp_cfg 
sc7180_mdp[] = {

  },
 };
+static const struct dpu_mdp_cfg sc8180x_mdp[] = {
+   {
+   .name = "top_0", .id = MDP_TOP,
+   .base = 0x0, .len = 0x45C,
+   .features = 0,
+   .highest_bank_bit = 0x3,
+   .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+   .reg_off = 0x2AC, .bit_off = 0},
+   .clk_ctrls[DPU_CLK_CTRL_VIG1] = {
+   .reg_off = 0x2B4, .bit_off = 0},
+   .clk_ctrls[DPU_CLK_CTRL_VIG2] = {
+   .reg_off = 0x2BC, .bit_off = 0},
+   .clk_ctrls[DPU_CLK_CTRL_VIG3] = {
+   .reg_off = 0x2C4, .bit_off = 0},
+   .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+   .reg_off = 0x2AC, .bit_off = 8},
+   .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
+   .reg_off = 0x2B4, .bit_off = 8},
+   .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+   .reg_off = 0x2BC, .bit_off = 8},
+   .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+   .reg_off = 0x2C4, .bit_off = 8},
+   },
+};
+
 static const struct dpu_mdp_cfg sm8250_mdp[] = {
  {
  .name = "top_0", .id = MDP_TOP,
@@ -861,6 +913,16 @@ static const struct dpu_intf_cfg 
sc7280_intf[] = {
  INTF_BLK("intf_5", INTF_5, 0x39000, INTF_DP, 
MSM_DP_CONTROLLER_1, 24, INTF_SC7280_MASK, MDP_SSPP_TOP0_INTR, 
22, 23),

 };
+static const struct dpu_intf_cfg sc8180x_intf[] = {
+   INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 
MSM_DP_CONTROLLER_0, 24, INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 
24, 25),
+   INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, 24, 
INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 26, 27),
+   INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, 24, 
INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 28, 29),
+   /* INTF_3 is for MST, wired to INTF_DP 0 and 1, use dummy 
index until this is supported */
+   INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 999, 24, 
INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 30, 31),
+   INTF_BLK("intf_4", INTF_4, 

Re: [Intel-gfx] [RFC 2/2] drm/i915/migrate: Evict and restore the ccs data

2022-02-17 Thread Lucas De Marchi

On Mon, Feb 07, 2022 at 03:07:43PM +0530, Ramalingam C wrote:

When we are swapping out the local memory obj on flat-ccs capable platform,
we need to capture the ccs data too along with main meory and we need to
restore it when we are swapping in the content.

Extracting and restoring the CCS data is done through a special cmd called
XY_CTRL_SURF_COPY_BLT

Signed-off-by: Ramalingam C 
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 283 +---
1 file changed, 155 insertions(+), 128 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 5bdab0b3c735..e60ae6ff1847 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -449,14 +449,146 @@ static bool wa_1209644611_applies(int ver, u32 size)
return height % 4 == 3 && height <= 8;
}

+/**
+ * DOC: Flat-CCS - Memory compression for Local memory
+ *
+ * On Xe-HP and later devices, we use dedicated compression control state (CCS)
+ * stored in local memory for each surface, to support the 3D and media
+ * compression formats.
+ *
+ * The memory required for the CCS of the entire local memory is 1/256 of the
+ * local memory size. So before the kernel boot, the required memory is 
reserved
+ * for the CCS data and a secure register will be programmed with the CCS base
+ * address.
+ *
+ * Flat CCS data needs to be cleared when a lmem object is allocated.
+ * And CCS data can be copied in and out of CCS region through
+ * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
+ *
+ * When we exaust the lmem, if the object's placements support smem, then we 
can
+ * directly decompress the compressed lmem object into smem and start using it
+ * from smem itself.
+ *
+ * But when we need to swapout the compressed lmem object into a smem region
+ * though objects' placement doesn't support smem, then we copy the lmem 
content
+ * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
+ * When the object is referred, lmem content will be swaped in along with
+ * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
+ * location.
+ *
+ *
+ * Flat-CCS Modifiers for different compression formats
+ * 
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS - used to indicate the buffers of Flat 
CCS
+ * render compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS, new hashing/compression algorithm is
+ * used. Render compression uses 128 byte compression blocks
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_MC_CCS -used to indicate the buffers of Flat CCS
+ * media compression formats. Though the general layout is same as
+ * I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS, new hashing/compression algorithm is
+ * used. Media compression uses 256 byte compression blocks.
+ *
+ * I915_FORMAT_MOD_F_TILED_DG2_RC_CCS_CC - used to indicate the buffers of Flat
+ * CCS clear color render compression formats. Unified compression format for
+ * clear color render compression. The genral layout is a tiled layout using
+ * 4Kb tiles i.e Tile4 layout.
+ */
+
+static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
+{
+   /* Mask the 3 LSB to use the PPGTT address space */
+   *cmd++ = MI_FLUSH_DW | flags;
+   *cmd++ = lower_32_bits(dst);
+   *cmd++ = upper_32_bits(dst);
+
+   return cmd;
+}
+
+static u32 calc_ctrl_surf_instr_size(struct drm_i915_private *i915, int size)
+{
+   u32 num_cmds, num_blks, total_size;
+
+   if (!GET_CCS_SIZE(i915, size))
+   return 0;
+
+   /*
+* XY_CTRL_SURF_COPY_BLT transfers CCS in 256 byte
+* blocks. one XY_CTRL_SURF_COPY_BLT command can
+* trnasfer upto 1024 blocks.
+*/
+   num_blks = GET_CCS_SIZE(i915, size);
+   num_cmds = (num_blks + (NUM_CCS_BLKS_PER_XFER - 1)) >> 10;
+   total_size = (XY_CTRL_SURF_INSTR_SIZE) * num_cmds;
+
+   /*
+* We need to add a flush before and after
+* XY_CTRL_SURF_COPY_BLT
+*/
+   total_size += 2 * MI_FLUSH_DW_SIZE;
+   return total_size;
+}
+
+static u32 *_i915_ctrl_surf_copy_blt(u32 *cmd, u64 src_addr, u64 dst_addr,
+u8 src_mem_access, u8 dst_mem_access,
+int src_mocs, int dst_mocs,
+u16 num_ccs_blocks)
+{
+   int i = num_ccs_blocks;
+
+   /*
+* The XY_CTRL_SURF_COPY_BLT instruction is used to copy the CCS
+* data in and out of the CCS region.
+*
+* We can copy at most 1024 blocks of 256 bytes using one
+* XY_CTRL_SURF_COPY_BLT instruction.
+*
+* In case we need to copy more than 1024 blocks, we need to add
+* another instruction to the same batch buffer.
+*
+* 1024 blocks of 256 bytes of CCS represent a total 256KB of CCS.
+*
+* 256 KB of CCS 

Re: [Freedreno] [PATCH v2 2/2] drm/msm/dpu: Add SC8180x to hw catalog

2022-02-17 Thread Dmitry Baryshkov

On 16/02/2022 10:19, Abhinav Kumar wrote:



On 2/15/2022 9:14 PM, Bjorn Andersson wrote:

On Tue 15 Feb 20:38 CST 2022, Abhinav Kumar wrote:




On 2/15/2022 6:14 PM, Bjorn Andersson wrote:

On Tue 15 Feb 11:42 CST 2022, Abhinav Kumar wrote:




On 2/15/2022 9:28 AM, Bjorn Andersson wrote:

On Tue 15 Feb 11:14 CST 2022, Abhinav Kumar wrote:




On 2/14/2022 8:33 PM, Bjorn Andersson wrote:

From: Rob Clark 

Add SC8180x to the hardware catalog, for initial support for the
platform. Due to limitations in the DP driver only one of the 
four DP

interfaces is left enabled.

The SC8180x platform supports the newly added DPU_INTF_WIDEBUS 
flag and
the Windows-on-Snapdragon bootloader leaves the widebus bit set, 
so this

is flagged appropriately to ensure widebus is disabled - for now.

Signed-off-by: Rob Clark 
[bjorn: Reworked intf and irq definitions]
Signed-off-by: Bjorn Andersson 
---

Changes since v1:
- Dropped widebus flag

 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c    | 129 
++

 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h    |   1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |   1 +
 drivers/gpu/drm/msm/msm_drv.c |   1 +
 4 files changed, 132 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c

index aa75991903a6..7ac0fe32df49 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -90,6 +90,17 @@
  BIT(MDP_INTF3_INTR) | \
  BIT(MDP_INTF4_INTR))
+#define IRQ_SC8180X_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
+  BIT(MDP_SSPP_TOP0_INTR2) | \
+  BIT(MDP_SSPP_TOP0_HIST_INTR) | \
+  BIT(MDP_INTF0_INTR) | \
+  BIT(MDP_INTF1_INTR) | \
+  BIT(MDP_INTF2_INTR) | \
+  BIT(MDP_INTF3_INTR) | \
+  BIT(MDP_INTF4_INTR) | \
+  BIT(MDP_INTF5_INTR) | \
+  BIT(MDP_AD4_0_INTR) | \
+  BIT(MDP_AD4_1_INTR))
 #define DEFAULT_PIXEL_RAM_SIZE    (50 * 1024)
 #define DEFAULT_DPU_LINE_WIDTH    2048
@@ -225,6 +236,22 @@ static const struct dpu_caps 
sm8150_dpu_caps = {

 .max_vdeci_exp = MAX_VERT_DECIMATION,
 };
+static const struct dpu_caps sc8180x_dpu_caps = {
+    .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+    .max_mixer_blendstages = 0xb,
+    .qseed_type = DPU_SSPP_SCALER_QSEED3,
+    .smart_dma_rev = DPU_SSPP_SMART_DMA_V2, /* TODO: v2.5 */
+    .ubwc_version = DPU_HW_UBWC_VER_30,
+    .has_src_split = true,
+    .has_dim_layer = true,
+    .has_idle_pc = true,
+    .has_3d_merge = true,
+    .max_linewidth = 4096,
+    .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
+    .max_hdeci_exp = MAX_HORZ_DECIMATION,
+    .max_vdeci_exp = MAX_VERT_DECIMATION,
+};
+
 static const struct dpu_caps sm8250_dpu_caps = {
 .max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
 .max_mixer_blendstages = 0xb,
@@ -293,6 +320,31 @@ static const struct dpu_mdp_cfg 
sc7180_mdp[] = {

 },
 };
+static const struct dpu_mdp_cfg sc8180x_mdp[] = {
+    {
+    .name = "top_0", .id = MDP_TOP,
+    .base = 0x0, .len = 0x45C,
+    .features = 0,
+    .highest_bank_bit = 0x3,
+    .clk_ctrls[DPU_CLK_CTRL_VIG0] = {
+    .reg_off = 0x2AC, .bit_off = 0},
+    .clk_ctrls[DPU_CLK_CTRL_VIG1] = {
+    .reg_off = 0x2B4, .bit_off = 0},
+    .clk_ctrls[DPU_CLK_CTRL_VIG2] = {
+    .reg_off = 0x2BC, .bit_off = 0},
+    .clk_ctrls[DPU_CLK_CTRL_VIG3] = {
+    .reg_off = 0x2C4, .bit_off = 0},
+    .clk_ctrls[DPU_CLK_CTRL_DMA0] = {
+    .reg_off = 0x2AC, .bit_off = 8},
+    .clk_ctrls[DPU_CLK_CTRL_DMA1] = {
+    .reg_off = 0x2B4, .bit_off = 8},
+    .clk_ctrls[DPU_CLK_CTRL_CURSOR0] = {
+    .reg_off = 0x2BC, .bit_off = 8},
+    .clk_ctrls[DPU_CLK_CTRL_CURSOR1] = {
+    .reg_off = 0x2C4, .bit_off = 8},
+    },
+};
+
 static const struct dpu_mdp_cfg sm8250_mdp[] = {
 {
 .name = "top_0", .id = MDP_TOP,
@@ -861,6 +913,16 @@ static const struct dpu_intf_cfg 
sc7280_intf[] = {
 INTF_BLK("intf_5", INTF_5, 0x39000, INTF_DP, 
MSM_DP_CONTROLLER_1, 24, INTF_SC7280_MASK, MDP_SSPP_TOP0_INTR, 
22, 23),

 };
+static const struct dpu_intf_cfg sc8180x_intf[] = {
+    INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 
MSM_DP_CONTROLLER_0, 24, INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 
24, 25),
+    INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, 24, 
INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 26, 27),
+    INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, 24, 
INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 28, 29),
+    /* INTF_3 is for MST, wired to INTF_DP 0 and 1, use dummy 
index until this is supported */
+    INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 999, 24, 
INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 30, 31),
+    INTF_BLK("intf_4", INTF_4, 0x6C000, INTF_DP, 
MSM_DP_CONTROLLER_1, 24, INTF_SC7180_MASK, MDP_SSPP_TOP0_INTR, 
20, 21),

Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface

2022-02-17 Thread kernel test robot
Hi Andi,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next 
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc4 
next-20220217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/Introduce-multitile-support/20220217-224547
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-a004 
(https://download.01.org/0day-ci/archive/20220218/202202180713.xhysmqw4-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
d271fc04d5b97b12e6b797c6067d3c96a8d7470e)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/b358d991c154dc27fa4ef2fc99f8819f4f3e97e7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Andi-Shyti/Introduce-multitile-support/20220217-224547
git checkout b358d991c154dc27fa4ef2fc99f8819f4f3e97e7
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> ld.lld: error: undefined symbol: __divdi3
   >>> referenced by intel_gt_sysfs_pm.c:35 
(drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:35)
   >>>   
gpu/drm/i915/gt/intel_gt_sysfs_pm.o:(rc6_residency_ms_show) in archive 
drivers/built-in.a
   >>> referenced by intel_gt_sysfs_pm.c:35 
(drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:35)
   >>>   
gpu/drm/i915/gt/intel_gt_sysfs_pm.o:(rc6p_residency_ms_show) in archive 
drivers/built-in.a
   >>> referenced by intel_gt_sysfs_pm.c:35 
(drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:35)
   >>>   
gpu/drm/i915/gt/intel_gt_sysfs_pm.o:(rc6pp_residency_ms_show) in archive 
drivers/built-in.a
   >>> referenced 1 more times

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


[PATCH 8/8] drm/i915/guc: Fix potential invalid pointer dereferences when decoding G2Hs

2022-02-17 Thread John . C . Harrison
From: John Harrison 

Some G2H handlers were reading the context id field from the payload
before checking the payload met the minimum length required.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b70b1ff46418..ea17dca68674 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3895,12 +3895,13 @@ int intel_guc_deregister_done_process_msg(struct 
intel_guc *guc,
  u32 len)
 {
struct intel_context *ce;
-   u32 ctx_id = msg[0];
+   u32 ctx_id;
 
if (unlikely(len < 1)) {
drm_err(_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
return -EPROTO;
}
+   ctx_id = msg[0];
 
ce = g2h_context_lookup(guc, ctx_id);
if (unlikely(!ce))
@@ -3946,12 +3947,13 @@ int intel_guc_sched_done_process_msg(struct intel_guc 
*guc,
 {
struct intel_context *ce;
unsigned long flags;
-   u32 ctx_id = msg[0];
+   u32 ctx_id;
 
if (unlikely(len < 2)) {
drm_err(_to_gt(guc)->i915->drm, "Invalid length %u\n", len);
return -EPROTO;
}
+   ctx_id = msg[0];
 
ce = g2h_context_lookup(guc, ctx_id);
if (unlikely(!ce))
-- 
2.25.1



[PATCH 1/8] drm/i915/guc: Do not conflate lrc_desc with GuC id for registration

2022-02-17 Thread John . C . Harrison
From: John Harrison 

The LRC descriptor pool is going away. So, stop using it as a check for
context registration, use the GuC id instead (being the thing that
actually gets registered with the GuC).

Also, rename the set/clear/query helper functions for context id
mappings to better reflect their purpose and to differentiate from
other registration related helper functions.

Signed-off-by: John Harrison 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 ++-
 1 file changed, 38 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b3a429a92c0d..7fb889e14995 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -514,31 +514,20 @@ static inline bool guc_submission_initialized(struct 
intel_guc *guc)
return !!guc->lrc_desc_pool_vaddr;
 }
 
-static inline void reset_lrc_desc(struct intel_guc *guc, u32 id)
+static inline void _reset_lrc_desc(struct intel_guc *guc, u32 id)
 {
-   if (likely(guc_submission_initialized(guc))) {
-   struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
-   unsigned long flags;
-
-   memset(desc, 0, sizeof(*desc));
+   struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
 
-   /*
-* xarray API doesn't have xa_erase_irqsave wrapper, so calling
-* the lower level functions directly.
-*/
-   xa_lock_irqsave(>context_lookup, flags);
-   __xa_erase(>context_lookup, id);
-   xa_unlock_irqrestore(>context_lookup, flags);
-   }
+   memset(desc, 0, sizeof(*desc));
 }
 
-static inline bool lrc_desc_registered(struct intel_guc *guc, u32 id)
+static inline bool ctx_id_mapped(struct intel_guc *guc, u32 id)
 {
return __get_context(guc, id);
 }
 
-static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,
-  struct intel_context *ce)
+static inline void set_ctx_id_mapping(struct intel_guc *guc, u32 id,
+ struct intel_context *ce)
 {
unsigned long flags;
 
@@ -551,6 +540,24 @@ static inline void set_lrc_desc_registered(struct 
intel_guc *guc, u32 id,
xa_unlock_irqrestore(>context_lookup, flags);
 }
 
+static inline void clr_ctx_id_mapping(struct intel_guc *guc, u32 id)
+{
+   unsigned long flags;
+
+   if (unlikely(!guc_submission_initialized(guc)))
+   return;
+
+   _reset_lrc_desc(guc, id);
+
+   /*
+* xarray API doesn't have xa_erase_irqsave wrapper, so calling
+* the lower level functions directly.
+*/
+   xa_lock_irqsave(>context_lookup, flags);
+   __xa_erase(>context_lookup, id);
+   xa_unlock_irqrestore(>context_lookup, flags);
+}
+
 static void decr_outstanding_submission_g2h(struct intel_guc *guc)
 {
if (atomic_dec_and_test(>outstanding_submission_g2h))
@@ -795,7 +802,7 @@ static int __guc_wq_item_append(struct i915_request *rq)
GEM_BUG_ON(!atomic_read(>guc_id.ref));
GEM_BUG_ON(context_guc_id_invalid(ce));
GEM_BUG_ON(context_wait_for_deregister_to_register(ce));
-   GEM_BUG_ON(!lrc_desc_registered(ce_to_guc(ce), ce->guc_id.id));
+   GEM_BUG_ON(!ctx_id_mapped(ce_to_guc(ce), ce->guc_id.id));
 
/* Insert NOOP if this work queue item will wrap the tail pointer. */
if (wqi_size > wq_space_until_wrap(ce)) {
@@ -923,7 +930,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
if (submit) {
struct intel_context *ce = request_to_scheduling_context(last);
 
-   if (unlikely(!lrc_desc_registered(guc, ce->guc_id.id) &&
+   if (unlikely(!ctx_id_mapped(guc, ce->guc_id.id) &&
 !intel_context_is_banned(ce))) {
ret = guc_lrc_desc_pin(ce, false);
if (unlikely(ret == -EPIPE)) {
@@ -1897,7 +1904,7 @@ static bool need_tasklet(struct intel_guc *guc, struct 
i915_request *rq)
 
return submission_disabled(guc) || guc->stalled_request ||
!i915_sched_engine_is_empty(sched_engine) ||
-   !lrc_desc_registered(guc, ce->guc_id.id);
+   !ctx_id_mapped(guc, ce->guc_id.id);
 }
 
 static void guc_submit_request(struct i915_request *rq)
@@ -1954,7 +1961,7 @@ static void __release_guc_id(struct intel_guc *guc, 
struct intel_context *ce)
else
ida_simple_remove(>submission_state.guc_ids,
  ce->guc_id.id);
-   reset_lrc_desc(guc, ce->guc_id.id);
+   clr_ctx_id_mapping(guc, ce->guc_id.id);
set_context_guc_id_invalid(ce);
}
if (!list_empty(>guc_id.link))
@@ -2250,10 +2257,10 @@ static int guc_lrc_desc_pin(struct intel_context *ce, 
bool loop)
 

[PATCH 2/8] drm/i915/guc: Add an explicit 'submission_initialized' flag

2022-02-17 Thread John . C . Harrison
From: John Harrison 

The LRC descriptor pool is going away. So, stop using it as a check
for whether submission has been initialised or not.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 9d779de16613..568eb6352ef0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -137,6 +137,8 @@ struct intel_guc {
bool submission_supported;
/** @submission_selected: tracks whether the user enabled GuC 
submission */
bool submission_selected;
+   /** @submission_initialized: tracks whether GuC submission has been 
initialised */
+   bool submission_initialized;
/**
 * @rc_supported: tracks whether we support GuC rc on the current 
platform
 */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 7fb889e14995..11bf56b5a266 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -511,7 +511,7 @@ static void guc_lrc_desc_pool_destroy(struct intel_guc *guc)
 
 static inline bool guc_submission_initialized(struct intel_guc *guc)
 {
-   return !!guc->lrc_desc_pool_vaddr;
+   return guc->submission_initialized;
 }
 
 static inline void _reset_lrc_desc(struct intel_guc *guc, u32 id)
@@ -1813,7 +1813,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
struct intel_gt *gt = guc_to_gt(guc);
int ret;
 
-   if (guc->lrc_desc_pool)
+   if (guc->submission_initialized)
return 0;
 
ret = guc_lrc_desc_pool_create(guc);
@@ -1845,19 +1845,21 @@ int intel_guc_submission_init(struct intel_guc *guc)
INIT_DELAYED_WORK(>timestamp.work, guc_timestamp_ping);
guc->timestamp.ping_delay = (POLL_TIME_CLKS / gt->clock_frequency + 1) 
* HZ;
guc->timestamp.shift = gpm_timestamp_shift(gt);
+   guc->submission_initialized = true;
 
return 0;
 }
 
 void intel_guc_submission_fini(struct intel_guc *guc)
 {
-   if (!guc->lrc_desc_pool)
+   if (!guc->submission_initialized)
return;
 
guc_flush_destroyed_contexts(guc);
guc_lrc_desc_pool_destroy(guc);
i915_sched_engine_put(guc->sched_engine);
bitmap_free(guc->submission_state.guc_ids_bitmap);
+   guc->submission_initialized = false;
 }
 
 static inline void queue_request(struct i915_sched_engine *sched_engine,
-- 
2.25.1



[PATCH 0/8] Prep work for next GuC release

2022-02-17 Thread John . C . Harrison
From: John Harrison 

The next GuC firmware release includes some significant backwards
breaking API changes. One such is that there is no longer an LRC
descriptor pool. A bunch of prep work for that change can be done in
advance - the descriptor pool was being used for things it shouldn't
really have been used for anyway.

Signed-off-by: John Harrison 


John Harrison (8):
  drm/i915/guc: Do not conflate lrc_desc with GuC id for registration
  drm/i915/guc: Add an explicit 'submission_initialized' flag
  drm/i915/guc: Better name for context id limit
  drm/i915/guc: Split guc_lrc_desc_pin apart
  drm/i915/guc: Move lrc desc setup to where it is needed
  drm/i915/guc: Rename desc_idx to ctx_id
  drm/i915/guc: Drop obsolete H2G definitions
  drm/i915/guc: Fix potential invalid pointer dereferences when decoding
G2Hs

 drivers/gpu/drm/i915/gt/intel_context.c   |   2 +-
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |   2 -
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|   2 +
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   4 +-
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 183 ++
 drivers/gpu/drm/i915/gt/uc/selftest_guc.c |   2 +-
 6 files changed, 112 insertions(+), 83 deletions(-)

-- 
2.25.1



[PATCH 7/8] drm/i915/guc: Drop obsolete H2G definitions

2022-02-17 Thread John . C . Harrison
From: John Harrison 

The CTB registration process changed significantly a while back using
a single KLV based H2G. So drop the original and now obsolete H2G
definitions.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 7afdadc7656f..e77f955435ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -131,8 +131,6 @@ enum intel_guc_action {
INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
-   INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
-   INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
INTEL_GUC_ACTION_DEREGISTER_CONTEXT_DONE = 0x4600,
INTEL_GUC_ACTION_REGISTER_CONTEXT_MULTI_LRC = 0x4601,
INTEL_GUC_ACTION_CLIENT_SOFT_RESET = 0x5507,
-- 
2.25.1



[PATCH 4/8] drm/i915/guc: Split guc_lrc_desc_pin apart

2022-02-17 Thread John . C . Harrison
From: John Harrison 

The LRC descriptor pool is going away. Further, the function that was
populating it was also doing a bunch of logic about the context
registration sequence. So, split that code apart into separate state
setup and try to register functions. Note that some of those 'try to
register' code paths actually undo the state setup and leave it to be
redone again later (with potentially different values). This is
inefficient. The next patch will correct this.

Also, move a comment about ignoring return values to the place where
the return values are actually ignored.

Signed-off-by: John Harrison 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 45 ---
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index ad784e8068c7..0ab2d1a24bf6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -634,7 +634,7 @@ int intel_guc_wait_for_idle(struct intel_guc *guc, long 
timeout)
  true, timeout);
 }
 
-static int guc_lrc_desc_pin(struct intel_context *ce, bool loop);
+static int try_context_registration(struct intel_context *ce, bool loop);
 
 static int __guc_add_request(struct intel_guc *guc, struct i915_request *rq)
 {
@@ -932,7 +932,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
 
if (unlikely(!ctx_id_mapped(guc, ce->guc_id.id) &&
 !intel_context_is_banned(ce))) {
-   ret = guc_lrc_desc_pin(ce, false);
+   ret = try_context_registration(ce, false);
if (unlikely(ret == -EPIPE)) {
goto deadlk;
} else if (ret == -EBUSY) {
@@ -2237,17 +2237,13 @@ static void guc_context_policy_init(struct 
intel_engine_cs *engine,
desc->preemption_timeout = engine->props.preempt_timeout_ms * 1000;
 }
 
-static int guc_lrc_desc_pin(struct intel_context *ce, bool loop)
+static void prepare_context_registration_info(struct intel_context *ce)
 {
struct intel_engine_cs *engine = ce->engine;
-   struct intel_runtime_pm *runtime_pm = engine->uncore->rpm;
struct intel_guc *guc = >gt->uc.guc;
u32 desc_idx = ce->guc_id.id;
struct guc_lrc_desc *desc;
-   bool context_registered;
-   intel_wakeref_t wakeref;
struct intel_context *child;
-   int ret = 0;
 
GEM_BUG_ON(!engine->mask);
GEM_BUG_ON(!sched_state_is_init(ce));
@@ -2259,8 +2255,6 @@ static int guc_lrc_desc_pin(struct intel_context *ce, 
bool loop)
GEM_BUG_ON(i915_gem_object_is_lmem(guc->ct.vma->obj) !=
   i915_gem_object_is_lmem(ce->ring->vma->obj));
 
-   context_registered = ctx_id_mapped(guc, desc_idx);
-
clr_ctx_id_mapping(guc, desc_idx);
set_ctx_id_mapping(guc, desc_idx, ce);
 
@@ -2308,6 +2302,21 @@ static int guc_lrc_desc_pin(struct intel_context *ce, 
bool loop)
 
clear_children_join_go_memory(ce);
}
+}
+
+static int try_context_registration(struct intel_context *ce, bool loop)
+{
+   struct intel_engine_cs *engine = ce->engine;
+   struct intel_runtime_pm *runtime_pm = engine->uncore->rpm;
+   struct intel_guc *guc = >gt->uc.guc;
+   intel_wakeref_t wakeref;
+   u32 desc_idx = ce->guc_id.id;
+   bool context_registered;
+   int ret = 0;
+
+   context_registered = ctx_id_mapped(guc, desc_idx);
+
+   prepare_context_registration_info(ce);
 
/*
 * The context_lookup xarray is used to determine if the hardware
@@ -3145,7 +3154,7 @@ static int guc_request_alloc(struct i915_request *rq)
if (unlikely(ret < 0))
return ret;
if (context_needs_register(ce, !!ret)) {
-   ret = guc_lrc_desc_pin(ce, true);
+   ret = try_context_registration(ce, true);
if (unlikely(ret)) {/* unwind */
if (ret == -EPIPE) {
disable_submission(guc);
@@ -3633,9 +3642,17 @@ static void guc_set_default_submission(struct 
intel_engine_cs *engine)
 static inline void guc_kernel_context_pin(struct intel_guc *guc,
  struct intel_context *ce)
 {
+   /*
+* Note: we purposefully do not check the returns below because
+* the registration can only fail if a reset is just starting.
+* This is called at the end of reset so presumably another reset
+* isn't happening and even it did this code would be run again.
+*/
+
if (context_guc_id_invalid(ce))
pin_guc_id(guc, ce);
-   guc_lrc_desc_pin(ce, true);
+
+   try_context_registration(ce, true);
 }
 
 static inline void guc_init_lrc_mapping(struct intel_guc *guc)
@@ -3653,13 +3670,7 @@ static inline void 

[PATCH 6/8] drm/i915/guc: Rename desc_idx to ctx_id

2022-02-17 Thread John . C . Harrison
From: John Harrison 

The LRC descriptor pool is going away. So, stop naming context ids as
descriptor pool indecies.

While at it, add a bunch of missing line feeds to some error messages.

Signed-off-by: John Harrison 
---
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56 +--
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index aa74ec74194a..b70b1ff46418 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2245,7 +2245,7 @@ static void prepare_context_registration_info(struct 
intel_context *ce)
 {
struct intel_engine_cs *engine = ce->engine;
struct intel_guc *guc = >gt->uc.guc;
-   u32 desc_idx = ce->guc_id.id;
+   u32 ctx_id = ce->guc_id.id;
struct guc_lrc_desc *desc;
struct intel_context *child;
 
@@ -2258,10 +2258,10 @@ static void prepare_context_registration_info(struct 
intel_context *ce)
GEM_BUG_ON(i915_gem_object_is_lmem(guc->ct.vma->obj) !=
   i915_gem_object_is_lmem(ce->ring->vma->obj));
 
-   clr_ctx_id_mapping(guc, desc_idx);
-   set_ctx_id_mapping(guc, desc_idx, ce);
+   clr_ctx_id_mapping(guc, ctx_id);
+   set_ctx_id_mapping(guc, ctx_id, ce);
 
-   desc = __get_lrc_desc(guc, desc_idx);
+   desc = __get_lrc_desc(guc, ctx_id);
desc->engine_class = engine_class_to_guc_class(engine->class);
desc->engine_submit_mask = engine->logical_mask;
desc->hw_context_desc = ce->lrc.lrca;
@@ -2313,17 +2313,17 @@ static int try_context_registration(struct 
intel_context *ce, bool loop)
struct intel_runtime_pm *runtime_pm = engine->uncore->rpm;
struct intel_guc *guc = >gt->uc.guc;
intel_wakeref_t wakeref;
-   u32 desc_idx = ce->guc_id.id;
+   u32 ctx_id = ce->guc_id.id;
bool context_registered;
int ret = 0;
 
GEM_BUG_ON(!sched_state_is_init(ce));
 
-   context_registered = ctx_id_mapped(guc, desc_idx);
+   context_registered = ctx_id_mapped(guc, ctx_id);
 
if (context_registered)
-   clr_ctx_id_mapping(guc, desc_idx);
-   set_ctx_id_mapping(guc, desc_idx, ce);
+   clr_ctx_id_mapping(guc, ctx_id);
+   set_ctx_id_mapping(guc, ctx_id, ce);
 
/*
 * The context_lookup xarray is used to determine if the hardware
@@ -2349,7 +2349,7 @@ static int try_context_registration(struct intel_context 
*ce, bool loop)
}
spin_unlock_irqrestore(>guc_state.lock, flags);
if (unlikely(disabled)) {
-   clr_ctx_id_mapping(guc, desc_idx);
+   clr_ctx_id_mapping(guc, ctx_id);
return 0;   /* Will get registered later */
}
 
@@ -2365,9 +2365,9 @@ static int try_context_registration(struct intel_context 
*ce, bool loop)
with_intel_runtime_pm(runtime_pm, wakeref)
ret = register_context(ce, loop);
if (unlikely(ret == -EBUSY)) {
-   clr_ctx_id_mapping(guc, desc_idx);
+   clr_ctx_id_mapping(guc, ctx_id);
} else if (unlikely(ret == -ENODEV)) {
-   clr_ctx_id_mapping(guc, desc_idx);
+   clr_ctx_id_mapping(guc, ctx_id);
ret = 0;/* Will get registered later */
}
}
@@ -3864,26 +3864,26 @@ void intel_guc_submission_init_early(struct intel_guc 
*guc)
 }
 
 static inline struct intel_context *
-g2h_context_lookup(struct intel_guc *guc, u32 desc_idx)
+g2h_context_lookup(struct intel_guc *guc, u32 ctx_id)
 {
struct intel_context *ce;
 
-   if (unlikely(desc_idx >= GUC_MAX_CONTEXT_ID)) {
+   if (unlikely(ctx_id >= GUC_MAX_CONTEXT_ID)) {
drm_err(_to_gt(guc)->i915->drm,
-   "Invalid desc_idx %u", desc_idx);
+   "Invalid ctx_id %u\n", ctx_id);
return NULL;
}
 
-   ce = __get_context(guc, desc_idx);
+   ce = __get_context(guc, ctx_id);
if (unlikely(!ce)) {
drm_err(_to_gt(guc)->i915->drm,
-   "Context is NULL, desc_idx %u", desc_idx);
+   "Context is NULL, ctx_id %u\n", ctx_id);
return NULL;
}
 
if (unlikely(intel_context_is_child(ce))) {
drm_err(_to_gt(guc)->i915->drm,
-   "Context is child, desc_idx %u", desc_idx);
+   "Context is child, ctx_id %u\n", ctx_id);
return NULL;
}
 
@@ -3895,14 +3895,14 @@ int intel_guc_deregister_done_process_msg(struct 
intel_guc *guc,
  u32 len)
 {
struct intel_context *ce;
-   u32 desc_idx = msg[0];
+   u32 ctx_id = msg[0];
 
  

[PATCH 3/8] drm/i915/guc: Better name for context id limit

2022-02-17 Thread John . C . Harrison
From: John Harrison 

The LRC descriptor pool is going away. So, stop using it as the limit
for how many context ids are available.

While at it, also update a kzalloc(sizeof()*count) to be a
kcalloc(count,size).

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/intel_context.c  |  2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h  |  4 ++--
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16 
 drivers/gpu/drm/i915/gt/uc/selftest_guc.c|  2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 5d0ec7c49b6a..d87145b8fca0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -400,7 +400,7 @@ intel_context_init(struct intel_context *ce, struct 
intel_engine_cs *engine)
INIT_LIST_HEAD(>guc_state.fences);
INIT_LIST_HEAD(>guc_state.requests);
 
-   ce->guc_id.id = GUC_INVALID_LRC_ID;
+   ce->guc_id.id = GUC_INVALID_CONTEXT_ID;
INIT_LIST_HEAD(>guc_id.link);
 
INIT_LIST_HEAD(>destroyed_link);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 6a4612a852e2..11099f0320ce 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -32,8 +32,8 @@
 #define GUC_CLIENT_PRIORITY_NORMAL 3
 #define GUC_CLIENT_PRIORITY_NUM4
 
-#define GUC_MAX_LRC_DESCRIPTORS65535
-#defineGUC_INVALID_LRC_ID  GUC_MAX_LRC_DESCRIPTORS
+#define GUC_MAX_CONTEXT_ID 65535
+#defineGUC_INVALID_CONTEXT_ID  GUC_MAX_CONTEXT_ID
 
 #define GUC_RENDER_ENGINE  0
 #define GUC_VIDEO_ENGINE   1
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 11bf56b5a266..ad784e8068c7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -354,12 +354,12 @@ request_to_scheduling_context(struct i915_request *rq)
 
 static inline bool context_guc_id_invalid(struct intel_context *ce)
 {
-   return ce->guc_id.id == GUC_INVALID_LRC_ID;
+   return ce->guc_id.id == GUC_INVALID_CONTEXT_ID;
 }
 
 static inline void set_context_guc_id_invalid(struct intel_context *ce)
 {
-   ce->guc_id.id = GUC_INVALID_LRC_ID;
+   ce->guc_id.id = GUC_INVALID_CONTEXT_ID;
 }
 
 static inline struct intel_guc *ce_to_guc(struct intel_context *ce)
@@ -474,7 +474,7 @@ static struct guc_lrc_desc *__get_lrc_desc(struct intel_guc 
*guc, u32 index)
 {
struct guc_lrc_desc *base = guc->lrc_desc_pool_vaddr;
 
-   GEM_BUG_ON(index >= GUC_MAX_LRC_DESCRIPTORS);
+   GEM_BUG_ON(index >= GUC_MAX_CONTEXT_ID);
 
return [index];
 }
@@ -483,7 +483,7 @@ static inline struct intel_context *__get_context(struct 
intel_guc *guc, u32 id)
 {
struct intel_context *ce = xa_load(>context_lookup, id);
 
-   GEM_BUG_ON(id >= GUC_MAX_LRC_DESCRIPTORS);
+   GEM_BUG_ON(id >= GUC_MAX_CONTEXT_ID);
 
return ce;
 }
@@ -494,7 +494,7 @@ static int guc_lrc_desc_pool_create(struct intel_guc *guc)
int ret;
 
size = PAGE_ALIGN(sizeof(struct guc_lrc_desc) *
- GUC_MAX_LRC_DESCRIPTORS);
+ GUC_MAX_CONTEXT_ID);
ret = intel_guc_allocate_and_map_vma(guc, size, >lrc_desc_pool,
 (void 
**)>lrc_desc_pool_vaddr);
if (ret)
@@ -2441,7 +2441,7 @@ static void __guc_context_sched_disable(struct intel_guc 
*guc,
GUC_CONTEXT_DISABLE
};
 
-   GEM_BUG_ON(guc_id == GUC_INVALID_LRC_ID);
+   GEM_BUG_ON(guc_id == GUC_INVALID_CONTEXT_ID);
 
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_sched_disable(ce);
@@ -3840,7 +3840,7 @@ static bool __guc_submission_selected(struct intel_guc 
*guc)
 
 void intel_guc_submission_init_early(struct intel_guc *guc)
 {
-   guc->submission_state.num_guc_ids = GUC_MAX_LRC_DESCRIPTORS;
+   guc->submission_state.num_guc_ids = GUC_MAX_CONTEXT_ID;
guc->submission_supported = __guc_submission_supported(guc);
guc->submission_selected = __guc_submission_selected(guc);
 }
@@ -3850,7 +3850,7 @@ g2h_context_lookup(struct intel_guc *guc, u32 desc_idx)
 {
struct intel_context *ce;
 
-   if (unlikely(desc_idx >= GUC_MAX_LRC_DESCRIPTORS)) {
+   if (unlikely(desc_idx >= GUC_MAX_CONTEXT_ID)) {
drm_err(_to_gt(guc)->i915->drm,
"Invalid desc_idx %u", desc_idx);
return NULL;
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c 
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
index a115894d5896..1df71d0796ae 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -148,7 +148,7 @@ static int 

[PATCH 5/8] drm/i915/guc: Move lrc desc setup to where it is needed

2022-02-17 Thread John . C . Harrison
From: John Harrison 

The LRC descriptor was being initialised early on in the context
registration sequence. It could then be determined that the actual
registration needs to be delayed and the descriptor would be wiped
out. This is inefficient, so move the setup to later in the process
after the point of no return.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 0ab2d1a24bf6..aa74ec74194a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2153,6 +2153,8 @@ static int __guc_action_register_context(struct intel_guc 
*guc,
 0, loop);
 }
 
+static void prepare_context_registration_info(struct intel_context *ce);
+
 static int register_context(struct intel_context *ce, bool loop)
 {
struct intel_guc *guc = ce_to_guc(ce);
@@ -2163,6 +2165,8 @@ static int register_context(struct intel_context *ce, 
bool loop)
GEM_BUG_ON(intel_context_is_child(ce));
trace_intel_context_register(ce);
 
+   prepare_context_registration_info(ce);
+
if (intel_context_is_parent(ce))
ret = __guc_action_register_multi_lrc(guc, ce, ce->guc_id.id,
  offset, loop);
@@ -2246,7 +2250,6 @@ static void prepare_context_registration_info(struct 
intel_context *ce)
struct intel_context *child;
 
GEM_BUG_ON(!engine->mask);
-   GEM_BUG_ON(!sched_state_is_init(ce));
 
/*
 * Ensure LRC + CT vmas are is same region as write barrier is done
@@ -2314,9 +2317,13 @@ static int try_context_registration(struct intel_context 
*ce, bool loop)
bool context_registered;
int ret = 0;
 
+   GEM_BUG_ON(!sched_state_is_init(ce));
+
context_registered = ctx_id_mapped(guc, desc_idx);
 
-   prepare_context_registration_info(ce);
+   if (context_registered)
+   clr_ctx_id_mapping(guc, desc_idx);
+   set_ctx_id_mapping(guc, desc_idx, ce);
 
/*
 * The context_lookup xarray is used to determine if the hardware
-- 
2.25.1



Re: [PATCH v4 2/5] arm64: dts: qcom: sc7280: Add support for eDP panel on CRD

2022-02-17 Thread Doug Anderson
Hi,

On Thu, Feb 10, 2022 at 3:58 AM Sankeerth Billakanti
 wrote:
>
> +_gpios {
> +   edp_bl_power: edp-bl-power {
> +   pins = "gpio7";
> +   function = "normal";
> +   qcom,drive-strength = ;

As far as I can tell you're lacking:

#include 

...which is needed to use PMIC_GPIO_STRENGTH_LOW. I'm curious how
you're compiling?


[PATCH v3 2/2] drm/bridge: analogix_dp: Enable autosuspend

2022-02-17 Thread Brian Norris
DP AUX transactions can consist of many short operations. There's no
need to power things up/down in short intervals.

I pick an arbitrary 100ms; for the systems I'm testing (Rockchip
RK3399), runtime-PM transitions only take a few microseconds.

Signed-off-by: Brian Norris 
---

Changes in v3:
 - New in v3

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 16be279aed2c..d82a4ddf44e7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1121,7 +1121,7 @@ static int analogix_dp_get_modes(struct drm_connector 
*connector)
 
pm_runtime_get_sync(dp->dev);
edid = drm_get_edid(connector, >aux.ddc);
-   pm_runtime_put(dp->dev);
+   pm_runtime_put_autosuspend(dp->dev);
if (edid) {
drm_connector_update_edid_property(>connector,
   edid);
@@ -1642,7 +1642,7 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux 
*aux,
 
ret = analogix_dp_transfer(dp, msg);
 out:
-   pm_runtime_put(dp->dev);
+   pm_runtime_put_autosuspend(dp->dev);
 
return ret;
 }
@@ -1775,6 +1775,8 @@ int analogix_dp_bind(struct analogix_dp_device *dp, 
struct drm_device *drm_dev)
if (ret)
return ret;
 
+   pm_runtime_use_autosuspend(dp->dev);
+   pm_runtime_set_autosuspend_delay(dp->dev, 100);
pm_runtime_enable(dp->dev);
 
ret = analogix_dp_create_bridge(drm_dev, dp);
-- 
2.35.1.265.g69c8d7142f-goog



[PATCH v3 1/2] drm/bridge: analogix_dp: Grab runtime PM reference for DP-AUX

2022-02-17 Thread Brian Norris
If the display is not enable()d, then we aren't holding a runtime PM
reference here. Thus, it's easy to accidentally cause a hang, if user
space is poking around at /dev/drm_dp_aux0 at the "wrong" time.

Let's get a runtime PM reference, and check that we "see" the panel.
Don't force any panel power-up, etc., because that can be intrusive, and
that's not what other drivers do (see
drivers/gpu/drm/bridge/ti-sn65dsi86.c and
drivers/gpu/drm/bridge/parade-ps8640.c.)

Fixes: 0d97ad03f422 ("drm/bridge: analogix_dp: Remove duplicated code")
Cc: 
Cc: Tomeu Vizoso 
Signed-off-by: Brian Norris 
---

Changes in v3:
- Avoid panel power-up; just check for HPD state, and let the rest
  happen "as-is" (e.g., time out, if the caller hasn't prepared things
  properly)

Changes in v2:
- Fix spelling in Subject
- DRM_DEV_ERROR() -> drm_err()
- Propagate errors from un-analogix_dp_prepare_panel()

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index b7d2e4449cfa..16be279aed2c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1632,8 +1632,19 @@ static ssize_t analogix_dpaux_transfer(struct drm_dp_aux 
*aux,
   struct drm_dp_aux_msg *msg)
 {
struct analogix_dp_device *dp = to_dp(aux);
+   int ret;
+
+   pm_runtime_get_sync(dp->dev);
+
+   ret = analogix_dp_detect_hpd(dp);
+   if (ret)
+   goto out;
 
-   return analogix_dp_transfer(dp, msg);
+   ret = analogix_dp_transfer(dp, msg);
+out:
+   pm_runtime_put(dp->dev);
+
+   return ret;
 }
 
 struct analogix_dp_device *
-- 
2.35.1.265.g69c8d7142f-goog



Re: [PATCH v3 03/13] drm/msm/disp/dpu1: Add support for DSC in pingpong block

2022-02-17 Thread Marijn Suijten
On 2022-02-18 01:12:02, Dmitry Baryshkov wrote:
> On 18/02/2022 00:54, Marijn Suijten wrote:
> > On 2021-11-16 11:52:46, Vinod Koul wrote:
> >> In SDM845, DSC can be enabled by writing to pingpong block registers, so
> >> add support for DSC in hw_pp
> > 
> > Nit: I don't think the ", so add support for DSC in XXX" part in this
> > and other commit messages add anything.  You've already stated that in
> > the title, the commit body is just extra justification (and can perhaps
> > be filled with extra details about the patch contents instead).
> > 
> >> Reviewed-by: Abhinav Kumar 
> >> Reviewed-by: Dmitry Baryshkov 
> >> Signed-off-by: Vinod Koul 
> >> ---
> >>   .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   | 32 +++
> >>   .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   | 14 
> >>   2 files changed, 46 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> >> index 55766c97c4c8..47c6ab6caf95 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> >> @@ -28,6 +28,9 @@
> >>   #define PP_FBC_MODE 0x034
> >>   #define PP_FBC_BUDGET_CTL   0x038
> >>   #define PP_FBC_LOSSY_MODE   0x03C
> >> +#define PP_DSC_MODE 0x0a0
> >> +#define PP_DCE_DATA_IN_SWAP 0x0ac
> > 
> > This enum does not seem used here, is it used in another patch?
> > 
> >> +#define PP_DCE_DATA_OUT_SWAP0x0c8
> >>   
> >>   #define PP_DITHER_EN 0x000
> >>   #define PP_DITHER_BITDEPTH   0x004
> >> @@ -245,6 +248,32 @@ static u32 dpu_hw_pp_get_line_count(struct 
> >> dpu_hw_pingpong *pp)
> >>return line;
> >>   }
> >>   
> >> +static int dpu_hw_pp_dsc_enable(struct dpu_hw_pingpong *pp)
> >> +{
> >> +  struct dpu_hw_blk_reg_map *c = >hw;
> >> +
> >> +  DPU_REG_WRITE(c, PP_DSC_MODE, 1);
> >> +  return 0;
> >> +}
> >> +
> >> +static void dpu_hw_pp_dsc_disable(struct dpu_hw_pingpong *pp)
> >> +{
> >> +  struct dpu_hw_blk_reg_map *c = >hw;
> >> +
> >> +  DPU_REG_WRITE(c, PP_DSC_MODE, 0);
> >> +}
> >> +
> >> +static int dpu_hw_pp_setup_dsc(struct dpu_hw_pingpong *pp)
> >> +{
> >> +  struct dpu_hw_blk_reg_map *pp_c = >hw;
> >> +  int data;
> >> +
> >> +  data = DPU_REG_READ(pp_c, PP_DCE_DATA_OUT_SWAP);
> >> +  data |= BIT(18); /* endian flip */
> >> +  DPU_REG_WRITE(pp_c, PP_DCE_DATA_OUT_SWAP, data);
> >> +  return 0;
> >> +}
> >> +
> >>   static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
> >>unsigned long features)
> >>   {
> >> @@ -256,6 +285,9 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong 
> >> *c,
> >>c->ops.get_autorefresh = dpu_hw_pp_get_autorefresh_config;
> >>c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
> >>c->ops.get_line_count = dpu_hw_pp_get_line_count;
> >> +  c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
> >> +  c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
> >> +  c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
> >>   
> >>if (test_bit(DPU_PINGPONG_DITHER, ))
> >>c->ops.setup_dither = dpu_hw_pp_setup_dither;
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
> >> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> >> index 89d08a715c16..12758468d9ca 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> >> @@ -124,6 +124,20 @@ struct dpu_hw_pingpong_ops {
> >> */
> >>void (*setup_dither)(struct dpu_hw_pingpong *pp,
> >>struct dpu_hw_dither_cfg *cfg);
> >> +  /**
> >> +   * Enable DSC
> >> +   */
> >> +  int (*enable_dsc)(struct dpu_hw_pingpong *pp);
> >> +
> >> +  /**
> >> +   * Disable DSC
> >> +   */
> >> +  void (*disable_dsc)(struct dpu_hw_pingpong *pp);
> > 
> > It looks like most other callbacks in dpu1 use an `enable` function with
> > a boolean, instead of having a separate disable function.  That should
> > simplify the implementation down to a single ternary-if, too.  Would
> > that be desired to use here?
> 
> Just my 2c. I personally hate the unified functions with the boolean 
> argument. One of the reasons being the return value. Typically you do 
> not expect that the disable function can fail (or return an error). But 
> the unified function provides an error (to be handled) even in the 
> disable case.
> 
> Last, but not least, overall the kernel API is biased towards separate 
> enable and disable calls.

Fair enough, we should replace the other functions then.  Or perhaps
drop the return argument entirely, it's always zero for enable_dsc
anyway.  I doubt we'll ever add additional checks here?  If we do,
things can be split again.

- Marijn


Re: [REPOST PATCH v4 10/13] drm/msm/disp/dpu1: Add support for DSC in topology

2022-02-17 Thread Marijn Suijten
On 2022-02-10 16:04:20, Vinod Koul wrote:
> For DSC to work we typically need a 2,2,1 configuration. This should
> suffice for resolutions up to 4k. For more resolutions like 8k this won't
> work.
> 
> Also, it is better to use 2 LMs and DSC instances as half width results
> in lesser power consumption as compared to single LM, DSC at full width.
> 
> The panel has been tested only with 2,2,1 configuration, so for
> now we blindly create 2,2,1 topology when DSC is enabled
> 
> Co-developed-by: Abhinav Kumar 
> Signed-off-by: Abhinav Kumar 
> Signed-off-by: Vinod Koul 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 +
>  drivers/gpu/drm/msm/msm_drv.h   |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 95a7bf362e81..13ccb7b3cce5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -574,8 +574,21 @@ static struct msm_display_topology 
> dpu_encoder_get_topology(
>   topology.num_enc = 0;
>   topology.num_intf = intf_count;
>  
> + if (dpu_enc->dsc) {
> + /* In case of Display Stream Compression DSC, we would use

Just like elsewhere, since you wrote out Display Stream Compression,
write the "DSC" abbreviation between parentheses ()?

- Marijn

> +  * 2 encoders, 2 line mixers and 1 interface

+ 2 DSC "blocks"?

> +  * this is power optimal and can drive up to (including) 4k
> +  * screens
> +  */
> + topology.num_enc = 2;
> + topology.num_dsc = 2;
> + topology.num_intf = 1;
> + topology.num_lm = 2;
> + }
> +
>   return topology;
>  }
> +
>  static int dpu_encoder_virt_atomic_check(
>   struct drm_encoder *drm_enc,
>   struct drm_crtc_state *crtc_state,
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 6425a42e997c..994d895d1a47 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -103,12 +103,14 @@ enum msm_event_wait {
>   * @num_enc:  number of compression encoder blocks used
>   * @num_intf: number of interfaces the panel is mounted on
>   * @num_dspp: number of dspp blocks used
> + * @num_dsc:  number of Display Stream Compression (DSC) blocks used
>   */
>  struct msm_display_topology {
>   u32 num_lm;
>   u32 num_enc;
>   u32 num_intf;
>   u32 num_dspp;
> + u32 num_dsc;
>  };
>  
>  /**
> -- 
> 2.31.1
> 


Re: [REPOST PATCH v4 09/13] drm/msm: Add missing structure documentation

2022-02-17 Thread Marijn Suijten
Replace "missing structure" with "missing num_dspp field" in the title?

On 2022-02-10 16:04:19, Vinod Koul wrote:
> Somehow documentation for dspp was missed, so add that
> 
> Signed-off-by: Vinod Koul 
> ---
>  drivers/gpu/drm/msm/msm_drv.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index e7a312edfe67..6425a42e997c 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -102,6 +102,7 @@ enum msm_event_wait {
>   * @num_lm:   number of layer mixers used
>   * @num_enc:  number of compression encoder blocks used
>   * @num_intf: number of interfaces the panel is mounted on
> + * @num_dspp: number of dspp blocks used
>   */
>  struct msm_display_topology {
>   u32 num_lm;
> -- 
> 2.31.1
> 


Re: [REPOST PATCH v4 07/13] drm/msm/disp/dpu1: Add support for DSC in encoder

2022-02-17 Thread Marijn Suijten
On 2022-02-10 16:04:17, Vinod Koul wrote:
> We need to configure the encoder for DSC configuration and calculate DSC
> parameters for the given timing so this patch adds that support by
> adding dpu_encoder_prep_dsc() which is invoked when DSC is enabled.
> 
> Signed-off-by: Vinod Koul 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 164 +-
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h  |   8 +
>  2 files changed, 171 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 1e648db439f9..95a7bf362e81 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -21,6 +21,7 @@
>  #include "dpu_hw_intf.h"
>  #include "dpu_hw_ctl.h"
>  #include "dpu_hw_dspp.h"
> +#include "dpu_hw_dsc.h"
>  #include "dpu_formats.h"
>  #include "dpu_encoder_phys.h"
>  #include "dpu_crtc.h"
> @@ -136,6 +137,8 @@ enum dpu_enc_rc_states {
>   * @cur_slave:   As above but for the slave encoder.
>   * @hw_pp:   Handle to the pingpong blocks used for the display. No.
>   *   pingpong blocks can be different than num_phys_encs.
> + * @hw_dsc:  Handle to the DSC blocks used for the display.
> + * @dsc_mask:The bitmask of used DSC blocks.

No need for "^The" prefix here.

>   * @intfs_swapped:   Whether or not the phys_enc interfaces have been swapped
>   *   for partial update right-only cases, such as pingpong
>   *   split where virtual pingpong does not generate IRQs
> @@ -169,6 +172,7 @@ enum dpu_enc_rc_states {
>   * @topology:   topology of the display
>   * @idle_timeout:idle timeout duration in milliseconds
>   * @dp:  msm_dp pointer, for DP encoders
> + * @dsc: msm_display_dsc_config pointer, for DSC-enabled 
> encoders
>   */
>  struct dpu_encoder_virt {
>   struct drm_encoder base;
> @@ -182,6 +186,9 @@ struct dpu_encoder_virt {
>   struct dpu_encoder_phys *cur_master;
>   struct dpu_encoder_phys *cur_slave;
>   struct dpu_hw_pingpong *hw_pp[MAX_CHANNELS_PER_ENC];
> + struct dpu_hw_dsc *hw_dsc[MAX_CHANNELS_PER_ENC];
> +
> + unsigned int dsc_mask;
>  
>   bool intfs_swapped;
>  
> @@ -209,6 +216,9 @@ struct dpu_encoder_virt {
>   u32 idle_timeout;
>  
>   struct msm_dp *dp;
> +
> + /* DSC configuration */
> + struct msm_display_dsc_config *dsc;
>  };
>  
>  #define to_dpu_encoder_virt(x) container_of(x, struct dpu_encoder_virt, base)
> @@ -972,7 +982,8 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder 
> *drm_enc,
>   struct dpu_hw_blk *hw_ctl[MAX_CHANNELS_PER_ENC];
>   struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
>   struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
> - int num_lm, num_ctl, num_pp;
> + struct dpu_hw_blk *hw_dsc[MAX_CHANNELS_PER_ENC];
> + int num_lm, num_ctl, num_pp, num_dsc;
>   int i, j;
>  
>   if (!drm_enc) {
> @@ -1027,6 +1038,23 @@ static void dpu_encoder_virt_mode_set(struct 
> drm_encoder *drm_enc,
>   dpu_enc->hw_pp[i] = i < num_pp ? to_dpu_hw_pingpong(hw_pp[i])
>   : NULL;
>  
> + dpu_enc->dsc_mask = 0;
> +
> + if (dpu_enc->dsc) {
> + unsigned int dsc_mask = 0;

Perhaps move this definition outside the if, and unconditionally
perform:

dpu_enc->dsc_mask = dsc_mask;

Below the if, instead of having to write it twice when ->dsc is truthy?

> +
> + num_dsc = dpu_rm_get_assigned_resources(_kms->rm, 
> global_state,
> + drm_enc->base.id, 
> DPU_HW_BLK_DSC,
> + hw_dsc, 
> ARRAY_SIZE(hw_dsc));
> + for (i = 0; i < MAX_CHANNELS_PER_ENC; i++)
> + dpu_enc->hw_dsc[i] = i < num_dsc ? 
> to_dpu_hw_dsc(hw_dsc[i]) : NULL;
> +
> + for (i = 0; i < num_dsc; i++)
> + dsc_mask |= BIT(dpu_enc->hw_dsc[i]->idx - DSC_0);

Perhaps you can merge these loops?  Assuming hw_dsc is already
NULL-initialized, you only need to iterate to `i +
> + dpu_enc->dsc_mask = dsc_mask;
> + }
> +
>   cstate = to_dpu_crtc_state(drm_crtc->state);
>  
>   for (i = 0; i < num_lm; i++) {
> @@ -1739,6 +1767,127 @@ static void 
> dpu_encoder_vsync_event_work_handler(struct kthread_work *work)
>   nsecs_to_jiffies(ktime_to_ns(wakeup_time)));
>  }
>  
> +static void
> +dpu_encoder_dsc_pclk_param_calc(struct msm_display_dsc_config *dsc, u32 
> width)
> +{
> + int slice_count, slice_per_intf;
> + int bytes_in_slice, total_bytes_per_intf;
> +
> + if (!dsc || !dsc->drm->slice_width || !dsc->drm->slice_count) {
> + DPU_ERROR("Invalid DSC/slices\n");

What's the forward slash for?

> + 

Re: [REPOST PATCH v4 06/13] drm/msm/disp/dpu1: Add DSC support in hw_ctl

2022-02-17 Thread Marijn Suijten
On 2022-02-10 16:04:16, Vinod Koul wrote:
> Later gens of hardware have DSC bits moved to hw_ctl, so configure these
> bits so that DSC would work there as well
> 
> Reviewed-by: Dmitry Baryshkov 
> Signed-off-by: Vinod Koul 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 11 ++-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |  2 ++
>  2 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> index 02da9ecf71f1..49659165cea8 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
> @@ -25,6 +25,8 @@
>  #define   CTL_MERGE_3D_ACTIVE   0x0E4
>  #define   CTL_INTF_ACTIVE   0x0F4
>  #define   CTL_MERGE_3D_FLUSH0x100
> +#define   CTL_DSC_ACTIVE0x0E8
> +#define   CTL_DSC_FLUSH0x104
>  #define   CTL_INTF_FLUSH0x110
>  #define   CTL_INTF_MASTER   0x134
>  #define   CTL_FETCH_PIPE_ACTIVE 0x0FC
> @@ -34,6 +36,7 @@
>  
>  #define DPU_REG_RESET_TIMEOUT_US2000
>  #define  MERGE_3D_IDX   23
> +#define  DSC_IDX22

This define does not seem used in any of these patches.  Is that
intended?

>  #define  INTF_IDX   31
>  #define CTL_INVALID_BIT 0x
>  #define CTL_DEFAULT_GROUP_ID 0xf
> @@ -121,7 +124,6 @@ static u32 dpu_hw_ctl_get_pending_flush(struct dpu_hw_ctl 
> *ctx)
>  
>  static inline void dpu_hw_ctl_trigger_flush_v1(struct dpu_hw_ctl *ctx)
>  {
> -
>   if (ctx->pending_flush_mask & BIT(MERGE_3D_IDX))
>   DPU_REG_WRITE(>hw, CTL_MERGE_3D_FLUSH,
>   ctx->pending_merge_3d_flush_mask);
> @@ -506,6 +508,9 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl *ctx,
>   if ((test_bit(DPU_CTL_VM_CFG, >caps->features)))
>   mode_sel = CTL_DEFAULT_GROUP_ID  << 28;
>  
> + if (cfg->dsc)
> + DPU_REG_WRITE(>hw, CTL_DSC_FLUSH, cfg->dsc);
> +
>   if (cfg->intf_mode_sel == DPU_CTL_MODE_SEL_CMD)
>   mode_sel |= BIT(17);
>  
> @@ -517,6 +522,10 @@ static void dpu_hw_ctl_intf_cfg_v1(struct dpu_hw_ctl 
> *ctx,
>   if (cfg->merge_3d)
>   DPU_REG_WRITE(c, CTL_MERGE_3D_ACTIVE,
> BIT(cfg->merge_3d - MERGE_3D_0));
> + if (cfg->dsc) {
> + DPU_REG_WRITE(>hw, CTL_FLUSH, cfg->dsc);

Perhaps this should have been `DSC_IDX`, as the index to flush is set in
the CTL_DSC_FLUSH register already?  Should this go through
pending_flush_mask machinery?

> + DPU_REG_WRITE(c, CTL_DSC_ACTIVE, cfg->dsc);
> + }
>  }
>  
>  static void dpu_hw_ctl_intf_cfg(struct dpu_hw_ctl *ctx,
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> index 806c171e5df2..9847c9c46d6f 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
> @@ -40,6 +40,7 @@ struct dpu_hw_stage_cfg {
>   * @merge_3d:  3d merge block used
>   * @intf_mode_sel: Interface mode, cmd / vid
>   * @stream_sel:Stream selection for multi-stream interfaces
> + * @dsc:   DSC BIT masks

Bit masks of what?  Enabled DSCs?  A more verbose doc-comment is desired
here, matching the rest of the fields :) - something like "DSC block(s)
used" similar to merge_3d?  Or copy the docs from `dsc_mask`, which is
the value that is written into this field.

- Marijn

>   */
>  struct dpu_hw_intf_cfg {
>   enum dpu_intf intf;
> @@ -47,6 +48,7 @@ struct dpu_hw_intf_cfg {
>   enum dpu_merge_3d merge_3d;
>   enum dpu_ctl_mode_sel intf_mode_sel;
>   int stream_sel;
> + unsigned int dsc;
>  };
>  
>  /**
> -- 
> 2.31.1
> 


Re: [PATCH v3 03/13] drm/msm/disp/dpu1: Add support for DSC in pingpong block

2022-02-17 Thread Dmitry Baryshkov

On 18/02/2022 00:54, Marijn Suijten wrote:

On 2021-11-16 11:52:46, Vinod Koul wrote:

In SDM845, DSC can be enabled by writing to pingpong block registers, so
add support for DSC in hw_pp


Nit: I don't think the ", so add support for DSC in XXX" part in this
and other commit messages add anything.  You've already stated that in
the title, the commit body is just extra justification (and can perhaps
be filled with extra details about the patch contents instead).


Reviewed-by: Abhinav Kumar 
Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Vinod Koul 
---
  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   | 32 +++
  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   | 14 
  2 files changed, 46 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index 55766c97c4c8..47c6ab6caf95 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -28,6 +28,9 @@
  #define PP_FBC_MODE 0x034
  #define PP_FBC_BUDGET_CTL   0x038
  #define PP_FBC_LOSSY_MODE   0x03C
+#define PP_DSC_MODE 0x0a0
+#define PP_DCE_DATA_IN_SWAP 0x0ac


This enum does not seem used here, is it used in another patch?


+#define PP_DCE_DATA_OUT_SWAP0x0c8
  
  #define PP_DITHER_EN			0x000

  #define PP_DITHER_BITDEPTH0x004
@@ -245,6 +248,32 @@ static u32 dpu_hw_pp_get_line_count(struct dpu_hw_pingpong 
*pp)
return line;
  }
  
+static int dpu_hw_pp_dsc_enable(struct dpu_hw_pingpong *pp)

+{
+   struct dpu_hw_blk_reg_map *c = >hw;
+
+   DPU_REG_WRITE(c, PP_DSC_MODE, 1);
+   return 0;
+}
+
+static void dpu_hw_pp_dsc_disable(struct dpu_hw_pingpong *pp)
+{
+   struct dpu_hw_blk_reg_map *c = >hw;
+
+   DPU_REG_WRITE(c, PP_DSC_MODE, 0);
+}
+
+static int dpu_hw_pp_setup_dsc(struct dpu_hw_pingpong *pp)
+{
+   struct dpu_hw_blk_reg_map *pp_c = >hw;
+   int data;
+
+   data = DPU_REG_READ(pp_c, PP_DCE_DATA_OUT_SWAP);
+   data |= BIT(18); /* endian flip */
+   DPU_REG_WRITE(pp_c, PP_DCE_DATA_OUT_SWAP, data);
+   return 0;
+}
+
  static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
unsigned long features)
  {
@@ -256,6 +285,9 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
c->ops.get_autorefresh = dpu_hw_pp_get_autorefresh_config;
c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
c->ops.get_line_count = dpu_hw_pp_get_line_count;
+   c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
+   c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
+   c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
  
  	if (test_bit(DPU_PINGPONG_DITHER, ))

c->ops.setup_dither = dpu_hw_pp_setup_dither;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
index 89d08a715c16..12758468d9ca 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
@@ -124,6 +124,20 @@ struct dpu_hw_pingpong_ops {
 */
void (*setup_dither)(struct dpu_hw_pingpong *pp,
struct dpu_hw_dither_cfg *cfg);
+   /**
+* Enable DSC
+*/
+   int (*enable_dsc)(struct dpu_hw_pingpong *pp);
+
+   /**
+* Disable DSC
+*/
+   void (*disable_dsc)(struct dpu_hw_pingpong *pp);


It looks like most other callbacks in dpu1 use an `enable` function with
a boolean, instead of having a separate disable function.  That should
simplify the implementation down to a single ternary-if, too.  Would
that be desired to use here?


Just my 2c. I personally hate the unified functions with the boolean 
argument. One of the reasons being the return value. Typically you do 
not expect that the disable function can fail (or return an error). But 
the unified function provides an error (to be handled) even in the 
disable case.


Last, but not least, overall the kernel API is biased towards separate 
enable and disable calls.




- Marijn


+
+   /**
+* Setup DSC
+*/
+   int (*setup_dsc)(struct dpu_hw_pingpong *pp);
  };
  
  struct dpu_hw_merge_3d;

--
2.31.1




--
With best wishes
Dmitry


Re: [drm] *ERROR* mstb 0000000057b5b857 port 1: DPCD read on addr 0x4b0 for 1 bytes NAKed

2022-02-17 Thread Jocelyn Falempe

On 17/02/2022 19:15, Lyude Paul wrote:

Hi! Sorry for the late reply, I had to take some time off work unexpectedly.
This is normal (although not great TBH, I'm not sure we should be printing an
error message for that), it's the result of fwupd trying to probe the MST hub
to see if it's a specific Dell dock that can receive updates over DP aux, but
it's not smart enough to know it doesn't need to poke the DP aux ranges of
downstream branches or non-MST ports in general.
I think MST topology is not exposed to userspace, so it would be hard 
for fwupd to be smarter than that.




Would definitely accept patches to make this a non-error, or at least make
this a non-error when the read/writes come from userspace


I will try to provide a patch for this.

Thanks,

--

Jocelyn



Re: [PATCH V3 2/13] clk: mvebu: use time_is_before_eq_jiffies() instead of open coding it

2022-02-17 Thread Stephen Boyd
Quoting Qing Wang (2022-02-14 17:55:39)
> From: Wang Qing 
> 
> Use the helper function time_is_{before,after}_jiffies() to improve
> code readability.
> 
> Signed-off-by: Wang Qing 
> ---

Applied to clk-next


Re: [PATCH v3 03/13] drm/msm/disp/dpu1: Add support for DSC in pingpong block

2022-02-17 Thread Marijn Suijten
Hi Vinod,

I seem to have sent this review to v3 instead of the repost of v4.  It
should still apply the same, hope that's no issue.

- Marijn

On 2022-02-17 22:54:38, Marijn Suijten wrote:
> On 2021-11-16 11:52:46, Vinod Koul wrote:
> > In SDM845, DSC can be enabled by writing to pingpong block registers, so
> > add support for DSC in hw_pp
> 
> Nit: I don't think the ", so add support for DSC in XXX" part in this
> and other commit messages add anything.  You've already stated that in
> the title, the commit body is just extra justification (and can perhaps
> be filled with extra details about the patch contents instead).
> 
> > Reviewed-by: Abhinav Kumar 
> > Reviewed-by: Dmitry Baryshkov 
> > Signed-off-by: Vinod Koul 
> > ---
> >  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   | 32 +++
> >  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   | 14 
> >  2 files changed, 46 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> > index 55766c97c4c8..47c6ab6caf95 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> > @@ -28,6 +28,9 @@
> >  #define PP_FBC_MODE 0x034
> >  #define PP_FBC_BUDGET_CTL   0x038
> >  #define PP_FBC_LOSSY_MODE   0x03C
> > +#define PP_DSC_MODE 0x0a0
> > +#define PP_DCE_DATA_IN_SWAP 0x0ac
> 
> This enum does not seem used here, is it used in another patch?
> 
> > +#define PP_DCE_DATA_OUT_SWAP0x0c8
> >  
> >  #define PP_DITHER_EN   0x000
> >  #define PP_DITHER_BITDEPTH 0x004
> > @@ -245,6 +248,32 @@ static u32 dpu_hw_pp_get_line_count(struct 
> > dpu_hw_pingpong *pp)
> > return line;
> >  }
> >  
> > +static int dpu_hw_pp_dsc_enable(struct dpu_hw_pingpong *pp)
> > +{
> > +   struct dpu_hw_blk_reg_map *c = >hw;
> > +
> > +   DPU_REG_WRITE(c, PP_DSC_MODE, 1);
> > +   return 0;
> > +}
> > +
> > +static void dpu_hw_pp_dsc_disable(struct dpu_hw_pingpong *pp)
> > +{
> > +   struct dpu_hw_blk_reg_map *c = >hw;
> > +
> > +   DPU_REG_WRITE(c, PP_DSC_MODE, 0);
> > +}
> > +
> > +static int dpu_hw_pp_setup_dsc(struct dpu_hw_pingpong *pp)
> > +{
> > +   struct dpu_hw_blk_reg_map *pp_c = >hw;
> > +   int data;
> > +
> > +   data = DPU_REG_READ(pp_c, PP_DCE_DATA_OUT_SWAP);
> > +   data |= BIT(18); /* endian flip */
> > +   DPU_REG_WRITE(pp_c, PP_DCE_DATA_OUT_SWAP, data);
> > +   return 0;
> > +}
> > +
> >  static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
> > unsigned long features)
> >  {
> > @@ -256,6 +285,9 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong 
> > *c,
> > c->ops.get_autorefresh = dpu_hw_pp_get_autorefresh_config;
> > c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
> > c->ops.get_line_count = dpu_hw_pp_get_line_count;
> > +   c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
> > +   c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
> > +   c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
> >  
> > if (test_bit(DPU_PINGPONG_DITHER, ))
> > c->ops.setup_dither = dpu_hw_pp_setup_dither;
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> > index 89d08a715c16..12758468d9ca 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> > @@ -124,6 +124,20 @@ struct dpu_hw_pingpong_ops {
> >  */
> > void (*setup_dither)(struct dpu_hw_pingpong *pp,
> > struct dpu_hw_dither_cfg *cfg);
> > +   /**
> > +* Enable DSC
> > +*/
> > +   int (*enable_dsc)(struct dpu_hw_pingpong *pp);
> > +
> > +   /**
> > +* Disable DSC
> > +*/
> > +   void (*disable_dsc)(struct dpu_hw_pingpong *pp);
> 
> It looks like most other callbacks in dpu1 use an `enable` function with
> a boolean, instead of having a separate disable function.  That should
> simplify the implementation down to a single ternary-if, too.  Would
> that be desired to use here?
> 
> - Marijn
> 
> > +
> > +   /**
> > +* Setup DSC
> > +*/
> > +   int (*setup_dsc)(struct dpu_hw_pingpong *pp);
> >  };
> >  
> >  struct dpu_hw_merge_3d;
> > -- 
> > 2.31.1
> > 


Re: [PATCH v3 03/13] drm/msm/disp/dpu1: Add support for DSC in pingpong block

2022-02-17 Thread Marijn Suijten
On 2021-11-16 11:52:46, Vinod Koul wrote:
> In SDM845, DSC can be enabled by writing to pingpong block registers, so
> add support for DSC in hw_pp

Nit: I don't think the ", so add support for DSC in XXX" part in this
and other commit messages add anything.  You've already stated that in
the title, the commit body is just extra justification (and can perhaps
be filled with extra details about the patch contents instead).

> Reviewed-by: Abhinav Kumar 
> Reviewed-by: Dmitry Baryshkov 
> Signed-off-by: Vinod Koul 
> ---
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   | 32 +++
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h   | 14 
>  2 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 55766c97c4c8..47c6ab6caf95 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -28,6 +28,9 @@
>  #define PP_FBC_MODE 0x034
>  #define PP_FBC_BUDGET_CTL   0x038
>  #define PP_FBC_LOSSY_MODE   0x03C
> +#define PP_DSC_MODE 0x0a0
> +#define PP_DCE_DATA_IN_SWAP 0x0ac

This enum does not seem used here, is it used in another patch?

> +#define PP_DCE_DATA_OUT_SWAP0x0c8
>  
>  #define PP_DITHER_EN 0x000
>  #define PP_DITHER_BITDEPTH   0x004
> @@ -245,6 +248,32 @@ static u32 dpu_hw_pp_get_line_count(struct 
> dpu_hw_pingpong *pp)
>   return line;
>  }
>  
> +static int dpu_hw_pp_dsc_enable(struct dpu_hw_pingpong *pp)
> +{
> + struct dpu_hw_blk_reg_map *c = >hw;
> +
> + DPU_REG_WRITE(c, PP_DSC_MODE, 1);
> + return 0;
> +}
> +
> +static void dpu_hw_pp_dsc_disable(struct dpu_hw_pingpong *pp)
> +{
> + struct dpu_hw_blk_reg_map *c = >hw;
> +
> + DPU_REG_WRITE(c, PP_DSC_MODE, 0);
> +}
> +
> +static int dpu_hw_pp_setup_dsc(struct dpu_hw_pingpong *pp)
> +{
> + struct dpu_hw_blk_reg_map *pp_c = >hw;
> + int data;
> +
> + data = DPU_REG_READ(pp_c, PP_DCE_DATA_OUT_SWAP);
> + data |= BIT(18); /* endian flip */
> + DPU_REG_WRITE(pp_c, PP_DCE_DATA_OUT_SWAP, data);
> + return 0;
> +}
> +
>  static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
>   unsigned long features)
>  {
> @@ -256,6 +285,9 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
>   c->ops.get_autorefresh = dpu_hw_pp_get_autorefresh_config;
>   c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
>   c->ops.get_line_count = dpu_hw_pp_get_line_count;
> + c->ops.setup_dsc = dpu_hw_pp_setup_dsc;
> + c->ops.enable_dsc = dpu_hw_pp_dsc_enable;
> + c->ops.disable_dsc = dpu_hw_pp_dsc_disable;
>  
>   if (test_bit(DPU_PINGPONG_DITHER, ))
>   c->ops.setup_dither = dpu_hw_pp_setup_dither;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> index 89d08a715c16..12758468d9ca 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h
> @@ -124,6 +124,20 @@ struct dpu_hw_pingpong_ops {
>*/
>   void (*setup_dither)(struct dpu_hw_pingpong *pp,
>   struct dpu_hw_dither_cfg *cfg);
> + /**
> +  * Enable DSC
> +  */
> + int (*enable_dsc)(struct dpu_hw_pingpong *pp);
> +
> + /**
> +  * Disable DSC
> +  */
> + void (*disable_dsc)(struct dpu_hw_pingpong *pp);

It looks like most other callbacks in dpu1 use an `enable` function with
a boolean, instead of having a separate disable function.  That should
simplify the implementation down to a single ternary-if, too.  Would
that be desired to use here?

- Marijn

> +
> + /**
> +  * Setup DSC
> +  */
> + int (*setup_dsc)(struct dpu_hw_pingpong *pp);
>  };
>  
>  struct dpu_hw_merge_3d;
> -- 
> 2.31.1
> 


Re: [PATCH v8 3/4] drm/msm/dpu: revise timing engine programming to support widebus feature

2022-02-17 Thread Dmitry Baryshkov
On Fri, 18 Feb 2022 at 00:36, Kuogee Hsieh  wrote:
>
> Widebus feature will transmit two pixel data per pixel clock to interface.
> Timing engine provides driving force for this purpose. This patch base
> on HPG (Hardware Programming Guide) to revise timing engine register
> setting to accommodate both widebus and non widebus application. Also
> horizontal width parameters need to be reduced by half since two pixel
> data are clocked out per pixel clock when widebus feature enabled.
>
> Widebus can be enabled individually at DP. However at DSI, widebus have
> to be enabled along with DSC to achieve pixel clock rate be scaled down
> with same ratio as compression ratio when 10 bits per source component.
> Therefore this patch add no supports of DSI related widebus and compression.
>
> Changes in v2:
> -- remove compression related code from timing
> -- remove op_info from  struct msm_drm_private
> -- remove unnecessary wide_bus_en variables
> -- pass wide_bus_en into timing configuration by struct msm_dp
>
> Changes in v3:
> -- split patch into 3 patches
>
> Changes in v4:
> -- rework timing engine to not interfere with dsi/hdmi
> -- cover both widebus and compression
>
> Changes in v5:
> -- remove supports of DSI widebus and compression
>
> Changes in v7:
> -- split this patch into 3 patches
> -- add Tested-by
>
> Changes in v8:
> -- move new registers writes under DATA_HCTL_EN features check.
>
> Signed-off-by: Kuogee Hsieh 
> Tested-by: Bjorn Andersson 

Reviewed-by: Dmitry Baryshkov 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 10 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|  2 +
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   | 14 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 54 
> --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h|  2 +
>  5 files changed, 68 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 0d315b4..0c22839 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -208,6 +208,8 @@ struct dpu_encoder_virt {
>
> u32 idle_timeout;
>
> +   bool wide_bus_en;
> +
> struct msm_dp *dp;
>  };
>
> @@ -217,6 +219,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> 15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
>  };
>
> +
> +bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc)
> +{
> +   struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
> +
> +   return dpu_enc->wide_bus_en;
> +}
> +
>  static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong *hw_pp, 
> unsigned bpc)
>  {
> struct dpu_hw_dither_cfg dither_cfg = { 0 };
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> index 99a5d73..893d74d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> @@ -168,4 +168,6 @@ int dpu_encoder_get_linecount(struct drm_encoder 
> *drm_enc);
>   */
>  int dpu_encoder_get_frame_count(struct drm_encoder *drm_enc);
>
> +bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc);
> +
>  #endif /* __DPU_ENCODER_H__ */
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> index 185379b..2af2bb7 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
> @@ -110,6 +110,20 @@ static void drm_mode_to_intf_timing_params(
> timing->v_back_porch += timing->v_front_porch;
> timing->v_front_porch = 0;
> }
> +
> +   timing->wide_bus_en = 
> dpu_encoder_is_widebus_enabled(phys_enc->parent);
> +
> +   /*
> +* for DP, divide the horizonal parameters by 2 when
> +* widebus is enabled
> +*/
> +   if (phys_enc->hw_intf->cap->type == INTF_DP && timing->wide_bus_en) {
> +   timing->width = timing->width >> 1;
> +   timing->xres = timing->xres >> 1;
> +   timing->h_back_porch = timing->h_back_porch >> 1;
> +   timing->h_front_porch = timing->h_front_porch >> 1;
> +   timing->hsync_pulse_width = timing->hsync_pulse_width >> 1;
> +   }
>  }
>
>  static u32 get_horizontal_total(const struct intf_timing_params *timing)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> index c2cd185..4e4fa56 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> @@ -33,6 +33,7 @@
>  #define INTF_TP_COLOR1  0x05C
>  #define INTF_CONFIG20x060
>  #define INTF_DISPLAY_DATA_HCTL  0x064
> +#define INTF_ACTIVE_DATA_HCTL   0x068
>  #define INTF_FRAME_LINE_COUNT_EN0x0A8

Re: [PATCH v8 2/4] drm/msm/dpu: replace BIT(x) with correspond marco define string

2022-02-17 Thread Dmitry Baryshkov
On Fri, 18 Feb 2022 at 00:36, Kuogee Hsieh  wrote:
>
> To improve code readability, this patch replace BIT(x) with
> correspond register bit define string
>
> Signed-off-by: Kuogee Hsieh 

Reviewed-by: Dmitry Baryshkov 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> index 284f561..c2cd185 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> @@ -60,6 +60,12 @@
>
>  #define   INTF_MUX  0x25C
>
> +#define INTF_CFG_ACTIVE_H_EN   BIT(29)
> +#define INTF_CFG_ACTIVE_V_EN   BIT(30)
> +
> +#define INTF_CFG2_DATABUS_WIDENBIT(0)
> +#define INTF_CFG2_DATA_HCTL_EN BIT(4)
> +
>  static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf intf,
> const struct dpu_mdss_cfg *m,
> void __iomem *addr,
> @@ -130,13 +136,13 @@ static void dpu_hw_intf_setup_timing_engine(struct 
> dpu_hw_intf *ctx,
>
> if (active_h_end) {
> active_hctl = (active_h_end << 16) | active_h_start;
> -   intf_cfg |= BIT(29);/* ACTIVE_H_ENABLE */
> +   intf_cfg |= INTF_CFG_ACTIVE_H_EN;
> } else {
> active_hctl = 0;
> }
>
> if (active_v_end)
> -   intf_cfg |= BIT(30); /* ACTIVE_V_ENABLE */
> +   intf_cfg |= INTF_CFG_ACTIVE_V_EN;
>
> hsync_ctl = (hsync_period << 16) | p->hsync_pulse_width;
> display_hctl = (hsync_end_x << 16) | hsync_start_x;
> @@ -182,7 +188,7 @@ static void dpu_hw_intf_setup_timing_engine(struct 
> dpu_hw_intf *ctx,
> (0x21 << 8));
>
> if (ctx->cap->features & BIT(DPU_DATA_HCTL_EN)) {
> -   intf_cfg2 |= BIT(4);
> +   intf_cfg2 |= INTF_CFG2_DATA_HCTL_EN;
> display_data_hctl = display_hctl;
> DPU_REG_WRITE(c, INTF_CONFIG2, intf_cfg2);
> DPU_REG_WRITE(c, INTF_DISPLAY_DATA_HCTL, display_data_hctl);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>


-- 
With best wishes
Dmitry


Re: [REPOST PATCH v4 10/13] drm/msm/disp/dpu1: Add support for DSC in topology

2022-02-17 Thread Marijn Suijten
On 2022-02-10 16:04:20, Vinod Koul wrote:
> For DSC to work we typically need a 2,2,1 configuration. This should
> suffice for resolutions up to 4k. For more resolutions like 8k this won't
> work.
> 
> Also, it is better to use 2 LMs and DSC instances as half width results
> in lesser power consumption as compared to single LM, DSC at full width.
> 
> The panel has been tested only with 2,2,1 configuration, so for
> now we blindly create 2,2,1 topology when DSC is enabled
> 
> Co-developed-by: Abhinav Kumar 
> Signed-off-by: Abhinav Kumar 
> Signed-off-by: Vinod Koul 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 +
>  drivers/gpu/drm/msm/msm_drv.h   |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 95a7bf362e81..13ccb7b3cce5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -574,8 +574,21 @@ static struct msm_display_topology 
> dpu_encoder_get_topology(
>   topology.num_enc = 0;
>   topology.num_intf = intf_count;
>  
> + if (dpu_enc->dsc) {
> + /* In case of Display Stream Compression DSC, we would use
> +  * 2 encoders, 2 line mixers and 1 interface

LM is a layer mixer, not a line mixer, right?

- Marijn

> +  * this is power optimal and can drive up to (including) 4k
> +  * screens
> +  */
> + topology.num_enc = 2;
> + topology.num_dsc = 2;
> + topology.num_intf = 1;
> + topology.num_lm = 2;
> + }
> +
>   return topology;
>  }
> +
>  static int dpu_encoder_virt_atomic_check(
>   struct drm_encoder *drm_enc,
>   struct drm_crtc_state *crtc_state,
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 6425a42e997c..994d895d1a47 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -103,12 +103,14 @@ enum msm_event_wait {
>   * @num_enc:  number of compression encoder blocks used
>   * @num_intf: number of interfaces the panel is mounted on
>   * @num_dspp: number of dspp blocks used
> + * @num_dsc:  number of Display Stream Compression (DSC) blocks used
>   */
>  struct msm_display_topology {
>   u32 num_lm;
>   u32 num_enc;
>   u32 num_intf;
>   u32 num_dspp;
> + u32 num_dsc;
>  };
>  
>  /**
> -- 
> 2.31.1
> 


Re: [PATCH v8 1/4] drm/msm/dpu: adjust display_v_end for eDP and DP

2022-02-17 Thread Dmitry Baryshkov
On Fri, 18 Feb 2022 at 00:36, Kuogee Hsieh  wrote:
>
> The “DP timing” requires the active region to be defined in the
> bottom-right corner of the frame dimensions which is different
> with DSI. Therefore both display_h_end and display_v_end need
> to be adjusted accordingly. However current implementation has
> only display_h_end adjusted.
>
> Signed-off-by: Kuogee Hsieh 

Fixes: fc3a69ec68d3 ("drm/msm/dpu: intf timing path for displayport")
Reviewed-by: Dmitry Baryshkov 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> index 116e2b5..284f561 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> @@ -148,6 +148,7 @@ static void dpu_hw_intf_setup_timing_engine(struct 
> dpu_hw_intf *ctx,
> active_v_end = active_v_start + (p->yres * hsync_period) - 1;
>
> display_v_start += p->hsync_pulse_width + p->h_back_porch;
> +   display_v_end   -= p->h_front_porch;
>
> active_hctl = (active_h_end << 16) | active_h_start;
> display_hctl = active_hctl;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>


-- 
With best wishes
Dmitry


Re: [PATCH libdrm v2 00/25] Update Tegra support

2022-02-17 Thread Thierry Reding
On Thu, Feb 17, 2022 at 11:02:53PM +0300, Dmitry Osipenko wrote:
> 17.02.2022 22:16, Thierry Reding пишет:
> > From: Thierry Reding 
> > 
> > Hi all,
> > 
> > this is the userspace part of the kernel patches that were recently
> > merged into drm-next:
> > 
> >   https://patchwork.freedesktop.org/series/92378/
> > 
> > The goal is to provide a userspace implementation of the UAPI exposed by
> > the kernel and show its usage in some test programs that can also be
> > used for basic sanity testing. More complete userspace implementations
> > are available here:
> > 
> >   * https://github.com/cyndis/vaapi-tegra-driver
> >   * https://github.com/grate-driver/xf86-video-opentegra
> >   * https://github.com/grate-driver/grate
> > 
> > Changes in v2:
> > - implement vic_clear() as a helper using ->fill() (Michał Mirosław)
> > - rebase and fix a couple of Meson errors/warnings
> > 
> > Thierry
> > 
> > Thierry Reding (25):
> >   tegra: Indent according to .editorconfig
> >   tegra: Remove unused IOCTL implementations
> >   tegra: Extract common buffer object allocation code
> >   tegra: Fix mmap() of GEM buffer objects
> >   tegra: Add flink helpers
> >   tegra: Add PRIME support helpers
> >   tegra: Make API more consistent
> >   tegra: Install tegra-openclose test
> >   tegra: Update for new UABI
> >   tegra: Include private.h in list of source files
> >   tegra: Add channel APIs
> >   tegra: Add job and push buffer APIs
> >   tegra: Add syncpoint APIs
> >   tests: tegra: Add helper library for tests
> >   tests: tegra: Add gr2d-fill test
> >   tests: tegra: Add syncpt-wait test
> >   tests: tegra: Add syncpoint timeout test
> >   tests: tegra: Add VIC support
> >   tests: tegra: Add VIC 3.0 support
> >   tests: tegra: Add VIC 4.0 support
> >   tests: tegra: Add VIC 4.1 support
> >   tests: tegra: Add VIC 4.2 support
> >   tests: tegra: Add VIC clear test
> >   tests: tegra: Add VIC blit test
> >   tests: tegra: Add VIC flip test
> > 
> >  include/drm/tegra_drm.h  | 429 +++--
> >  tegra/channel.c  | 195 
> >  tegra/job.c  | 187 +++
> >  tegra/meson.build|   7 +-
> >  tegra/private.h  |  85 -
> >  tegra/pushbuf.c  | 184 +++
> >  tegra/syncpt.c   | 101 ++
> >  tegra/tegra-symbols.txt  |  27 +-
> >  tegra/tegra.c| 386 +++---
> >  tegra/tegra.h|  95 +-
> >  tests/tegra/.gitignore   |   3 +-
> >  tests/tegra/drm-test-tegra.c | 147 +
> >  tests/tegra/drm-test-tegra.h |  55 
> >  tests/tegra/drm-test.c   | 248 +++
> >  tests/tegra/drm-test.h   |  72 +
> >  tests/tegra/gr2d-fill.c  | 146 +
> >  tests/tegra/host1x.h |  34 ++
> >  tests/tegra/meson.build  |  88 +-
> >  tests/tegra/openclose.c  |  52 +--
> >  tests/tegra/syncpt-timeout.c | 163 ++
> >  tests/tegra/syncpt-wait.c| 151 +
> >  tests/tegra/vic-blit.c   | 333 +++
> >  tests/tegra/vic-clear.c  | 173 ++
> >  tests/tegra/vic-flip.c   | 333 +++
> >  tests/tegra/vic.c| 184 +++
> >  tests/tegra/vic.h| 181 +++
> >  tests/tegra/vic30.c  | 458 +++
> >  tests/tegra/vic30.h  | 439 ++
> >  tests/tegra/vic40.c  | 370 ++
> >  tests/tegra/vic40.h  | 285 +
> >  tests/tegra/vic41.c  | 374 ++
> >  tests/tegra/vic41.h  | 372 ++
> >  tests/tegra/vic42.c  | 374 ++
> >  tests/tegra/vic42.h  | 597 +++
> >  34 files changed, 7068 insertions(+), 260 deletions(-)
> 
> 
> Why do we need these tests in libdrm? Why not IGT?

Oops, sorry. I had meant to reply to your question in the previous
version. The idea was to have this minimal set of tests in libdrm as a
way to demonstrate how to use the various APIs. At the same time, this
is meant to serve as an easy way to validate that everything works from
the comparatively simple libdrm package.

But yes, adding more tests on top of this to IGT is something that I've
been pondering and I certainly wouldn't object if anyone else was going
to attempt to do so. I don't think IGT and libdrm need to be mutually
exclusive, though.

Thierry


signature.asc
Description: PGP signature


[PATCH v8 4/4] drm/msm/dp: enable widebus feature for display port

2022-02-17 Thread Kuogee Hsieh
Widebus feature will transmit two pixel data per pixel clock to interface.
This feature now is required to be enabled to easy migrant to higher
resolution applications in future. However since some legacy chipsets
does not support this feature, this feature is enabled base on chip's
hardware revision.

changes in v2:
-- remove compression related code from timing
-- remove op_info from  struct msm_drm_private
-- remove unnecessary wide_bus_en variables
-- pass wide_bus_en into timing configuration by struct msm_dp

Changes in v3:
-- split patch into 3 patches
-- enable widebus feature base on chip hardware revision

Changes in v5:
-- DP_INTF_CONFIG_DATABUS_WIDEN

Changes in v6:
-- static inline bool msm_dp_wide_bus_enable() in msm_drv.h

Changes in v7:
-- add Tested-by

Signed-off-by: Kuogee Hsieh 
Reported-by: kernel test robot 
Tested-by: Bjorn Andersson 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |  4 +++-
 drivers/gpu/drm/msm/dp/dp_catalog.c | 34 +++--
 drivers/gpu/drm/msm/dp/dp_catalog.h |  3 ++-
 drivers/gpu/drm/msm/dp/dp_ctrl.c| 13 +++
 drivers/gpu/drm/msm/dp/dp_ctrl.h|  1 +
 drivers/gpu/drm/msm/dp/dp_display.c | 30 +
 drivers/gpu/drm/msm/dp/dp_display.h |  2 ++
 drivers/gpu/drm/msm/dp/dp_panel.c   |  4 ++--
 drivers/gpu/drm/msm/dp/dp_panel.h   |  2 +-
 drivers/gpu/drm/msm/msm_drv.h   |  6 +
 10 files changed, 88 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0c22839..b2d23c2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2167,8 +2167,10 @@ int dpu_encoder_setup(struct drm_device *dev, struct 
drm_encoder *enc,
timer_setup(_enc->vsync_event_timer,
dpu_encoder_vsync_event_handler,
0);
-   else if (disp_info->intf_type == DRM_MODE_ENCODER_TMDS)
+   else if (disp_info->intf_type == DRM_MODE_ENCODER_TMDS) {
dpu_enc->dp = priv->dp[disp_info->h_tile_instance[0]];
+   dpu_enc->wide_bus_en = msm_dp_wide_bus_enable(dpu_enc->dp);
+   }
 
INIT_DELAYED_WORK(_enc->delayed_off_work,
dpu_encoder_off_work);
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c 
b/drivers/gpu/drm/msm/dp/dp_catalog.c
index 64f0b26..5c809c6f 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.c
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.c
@@ -24,6 +24,8 @@
 #define DP_INTERRUPT_STATUS_ACK_SHIFT  1
 #define DP_INTERRUPT_STATUS_MASK_SHIFT 2
 
+#define DP_INTF_CONFIG_DATABUS_WIDEN BIT(4)
+
 #define DP_INTERRUPT_STATUS1 \
(DP_INTR_AUX_I2C_DONE| \
DP_INTR_WRONG_ADDR | DP_INTR_TIMEOUT | \
@@ -483,6 +485,22 @@ int dp_catalog_ctrl_set_pattern_state_bit(struct 
dp_catalog *dp_catalog,
 }
 
 /**
+ * dp_catalog_hw_revision() - retrieve DP hw revision
+ *
+ * @dp_catalog: DP catalog structure
+ *
+ * Return: DP controller hw revision
+ *
+ */
+u32 dp_catalog_hw_revision(struct dp_catalog *dp_catalog)
+{
+   struct dp_catalog_private *catalog = container_of(dp_catalog,
+   struct dp_catalog_private, dp_catalog);
+
+   return dp_read_ahb(catalog, REG_DP_HW_VERSION);
+}
+
+/**
  * dp_catalog_ctrl_reset() - reset DP controller
  *
  * @dp_catalog: DP catalog structure
@@ -739,10 +757,11 @@ u32 dp_catalog_ctrl_read_phy_pattern(struct dp_catalog 
*dp_catalog)
 }
 
 /* panel related catalog functions */
-int dp_catalog_panel_timing_cfg(struct dp_catalog *dp_catalog)
+int dp_catalog_panel_timing_cfg(struct dp_catalog *dp_catalog, bool 
wide_bus_en)
 {
struct dp_catalog_private *catalog = container_of(dp_catalog,
struct dp_catalog_private, dp_catalog);
+   u32 reg;
 
dp_write_link(catalog, REG_DP_TOTAL_HOR_VER,
dp_catalog->total);
@@ -751,7 +770,18 @@ int dp_catalog_panel_timing_cfg(struct dp_catalog 
*dp_catalog)
dp_write_link(catalog, REG_DP_HSYNC_VSYNC_WIDTH_POLARITY,
dp_catalog->width_blanking);
dp_write_link(catalog, REG_DP_ACTIVE_HOR_VER, dp_catalog->dp_active);
-   dp_write_p0(catalog, MMSS_DP_INTF_CONFIG, 0);
+
+   reg = dp_read_p0(catalog, MMSS_DP_INTF_CONFIG);
+
+   if (wide_bus_en)
+   reg |= DP_INTF_CONFIG_DATABUS_WIDEN;
+   else
+   reg &= ~DP_INTF_CONFIG_DATABUS_WIDEN;
+
+
+   DRM_DEBUG_DP("wide_bus_en=%d reg=%x\n", wide_bus_en, reg);
+
+   dp_write_p0(catalog, MMSS_DP_INTF_CONFIG, reg);
return 0;
 }
 
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.h 
b/drivers/gpu/drm/msm/dp/dp_catalog.h
index 7dea101..a3a0129 100644
--- a/drivers/gpu/drm/msm/dp/dp_catalog.h
+++ b/drivers/gpu/drm/msm/dp/dp_catalog.h
@@ -95,6 +95,7 @@ void dp_catalog_ctrl_config_misc(struct 

[PATCH v8 1/4] drm/msm/dpu: adjust display_v_end for eDP and DP

2022-02-17 Thread Kuogee Hsieh
The “DP timing” requires the active region to be defined in the
bottom-right corner of the frame dimensions which is different
with DSI. Therefore both display_h_end and display_v_end need
to be adjusted accordingly. However current implementation has
only display_h_end adjusted.

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 116e2b5..284f561 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -148,6 +148,7 @@ static void dpu_hw_intf_setup_timing_engine(struct 
dpu_hw_intf *ctx,
active_v_end = active_v_start + (p->yres * hsync_period) - 1;
 
display_v_start += p->hsync_pulse_width + p->h_back_porch;
+   display_v_end   -= p->h_front_porch; 
 
active_hctl = (active_h_end << 16) | active_h_start;
display_hctl = active_hctl;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v8 3/4] drm/msm/dpu: revise timing engine programming to support widebus feature

2022-02-17 Thread Kuogee Hsieh
Widebus feature will transmit two pixel data per pixel clock to interface.
Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal width parameters need to be reduced by half since two pixel
data are clocked out per pixel clock when widebus feature enabled.

Widebus can be enabled individually at DP. However at DSI, widebus have
to be enabled along with DSC to achieve pixel clock rate be scaled down
with same ratio as compression ratio when 10 bits per source component.
Therefore this patch add no supports of DSI related widebus and compression.

Changes in v2:
-- remove compression related code from timing
-- remove op_info from  struct msm_drm_private
-- remove unnecessary wide_bus_en variables
-- pass wide_bus_en into timing configuration by struct msm_dp

Changes in v3:
-- split patch into 3 patches

Changes in v4:
-- rework timing engine to not interfere with dsi/hdmi
-- cover both widebus and compression

Changes in v5:
-- remove supports of DSI widebus and compression

Changes in v7:
-- split this patch into 3 patches
-- add Tested-by

Changes in v8:
-- move new registers writes under DATA_HCTL_EN features check.

Signed-off-by: Kuogee Hsieh 
Tested-by: Bjorn Andersson 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 10 
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|  2 +
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   | 14 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 54 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h|  2 +
 5 files changed, 68 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0d315b4..0c22839 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -208,6 +208,8 @@ struct dpu_encoder_virt {
 
u32 idle_timeout;
 
+   bool wide_bus_en;
+
struct msm_dp *dp;
 };
 
@@ -217,6 +219,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
 };
 
+
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc)
+{
+   struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+   return dpu_enc->wide_bus_en;
+}
+
 static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong *hw_pp, unsigned 
bpc)
 {
struct dpu_hw_dither_cfg dither_cfg = { 0 };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 99a5d73..893d74d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -168,4 +168,6 @@ int dpu_encoder_get_linecount(struct drm_encoder *drm_enc);
  */
 int dpu_encoder_get_frame_count(struct drm_encoder *drm_enc);
 
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc);
+
 #endif /* __DPU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 185379b..2af2bb7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -110,6 +110,20 @@ static void drm_mode_to_intf_timing_params(
timing->v_back_porch += timing->v_front_porch;
timing->v_front_porch = 0;
}
+
+   timing->wide_bus_en = dpu_encoder_is_widebus_enabled(phys_enc->parent);
+
+   /*
+* for DP, divide the horizonal parameters by 2 when
+* widebus is enabled
+*/
+   if (phys_enc->hw_intf->cap->type == INTF_DP && timing->wide_bus_en) {
+   timing->width = timing->width >> 1;
+   timing->xres = timing->xres >> 1;
+   timing->h_back_porch = timing->h_back_porch >> 1;
+   timing->h_front_porch = timing->h_front_porch >> 1;
+   timing->hsync_pulse_width = timing->hsync_pulse_width >> 1;
+   }
 }
 
 static u32 get_horizontal_total(const struct intf_timing_params *timing)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index c2cd185..4e4fa56 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -33,6 +33,7 @@
 #define INTF_TP_COLOR1  0x05C
 #define INTF_CONFIG20x060
 #define INTF_DISPLAY_DATA_HCTL  0x064
+#define INTF_ACTIVE_DATA_HCTL   0x068
 #define INTF_FRAME_LINE_COUNT_EN0x0A8
 #define INTF_FRAME_COUNT0x0AC
 #define   INTF_LINE_COUNT   0x0B0
@@ -96,15 +97,23 @@ static void dpu_hw_intf_setup_timing_engine(struct 
dpu_hw_intf *ctx,
u32 hsync_period, vsync_period;
u32 display_v_start, display_v_end;
u32 hsync_start_x, hsync_end_x;
+   u32 

[PATCH v8 2/4] drm/msm/dpu: replace BIT(x) with correspond marco define string

2022-02-17 Thread Kuogee Hsieh
To improve code readability, this patch replace BIT(x) with
correspond register bit define string

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 284f561..c2cd185 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -60,6 +60,12 @@
 
 #define   INTF_MUX  0x25C
 
+#define INTF_CFG_ACTIVE_H_EN   BIT(29)
+#define INTF_CFG_ACTIVE_V_EN   BIT(30)
+
+#define INTF_CFG2_DATABUS_WIDENBIT(0)
+#define INTF_CFG2_DATA_HCTL_EN BIT(4)
+
 static const struct dpu_intf_cfg *_intf_offset(enum dpu_intf intf,
const struct dpu_mdss_cfg *m,
void __iomem *addr,
@@ -130,13 +136,13 @@ static void dpu_hw_intf_setup_timing_engine(struct 
dpu_hw_intf *ctx,
 
if (active_h_end) {
active_hctl = (active_h_end << 16) | active_h_start;
-   intf_cfg |= BIT(29);/* ACTIVE_H_ENABLE */
+   intf_cfg |= INTF_CFG_ACTIVE_H_EN;
} else {
active_hctl = 0;
}
 
if (active_v_end)
-   intf_cfg |= BIT(30); /* ACTIVE_V_ENABLE */
+   intf_cfg |= INTF_CFG_ACTIVE_V_EN;
 
hsync_ctl = (hsync_period << 16) | p->hsync_pulse_width;
display_hctl = (hsync_end_x << 16) | hsync_start_x;
@@ -182,7 +188,7 @@ static void dpu_hw_intf_setup_timing_engine(struct 
dpu_hw_intf *ctx,
(0x21 << 8));
 
if (ctx->cap->features & BIT(DPU_DATA_HCTL_EN)) {
-   intf_cfg2 |= BIT(4);
+   intf_cfg2 |= INTF_CFG2_DATA_HCTL_EN;
display_data_hctl = display_hctl;
DPU_REG_WRITE(c, INTF_CONFIG2, intf_cfg2);
DPU_REG_WRITE(c, INTF_DISPLAY_DATA_HCTL, display_data_hctl);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v8 0/2] drm/msm/dpu: enable widebus feature base on chip hardware revision

2022-02-17 Thread Kuogee Hsieh
revise widebus timing engine programming and enable widebus feature base on chip

Kuogee Hsieh (4):
  drm/msm/dpu: adjust display_v_end for eDP and DP
  drm/msm/dpu: replace BIT(x) with correspond marco define string
  drm/msm/dpu:  revise timing engine programming to support widebus
feature
  drm/msm/dp: enable widebus feature for display port

 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 14 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|  2 +
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   | 14 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 63 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h|  2 +
 drivers/gpu/drm/msm/dp/dp_catalog.c| 34 +++-
 drivers/gpu/drm/msm/dp/dp_catalog.h|  3 +-
 drivers/gpu/drm/msm/dp/dp_ctrl.c   | 13 +++--
 drivers/gpu/drm/msm/dp/dp_ctrl.h   |  1 +
 drivers/gpu/drm/msm/dp/dp_display.c| 30 +++
 drivers/gpu/drm/msm/dp/dp_display.h|  2 +
 drivers/gpu/drm/msm/dp/dp_panel.c  |  4 +-
 drivers/gpu/drm/msm/dp/dp_panel.h  |  2 +-
 drivers/gpu/drm/msm/msm_drv.h  |  6 +++
 14 files changed, 164 insertions(+), 26 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



Re: [git pull] drm fixes for 5.17-rc5

2022-02-17 Thread pr-tracker-bot
The pull request you sent on Fri, 18 Feb 2022 06:02:24 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-02-18

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b3d971ec25346d6890e9e8f05b63f758cfcef8c5

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html


[PATCH] drm/i915/guc: Fix flag query helper function to not modify state

2022-02-17 Thread John . C . Harrison
From: John Harrison 

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

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

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index b3a429a92c0d..d9f4218f5ef4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -174,11 +174,8 @@ static inline void init_sched_state(struct intel_context 
*ce)
 __maybe_unused
 static bool sched_state_is_init(struct intel_context *ce)
 {
-   /*
-* XXX: Kernel contexts can have SCHED_STATE_NO_LOCK_REGISTERED after
-* suspend.
-*/
-   return !(ce->guc_state.sched_state &=
+   /* Kernel contexts can have SCHED_STATE_REGISTERED after suspend. */
+   return !(ce->guc_state.sched_state &
 ~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
 }
 
-- 
2.25.1



Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/dg2: Enable 5th port

2022-02-17 Thread Lucas De Marchi

On Fri, Feb 18, 2022 at 12:12:21AM +0530, Ramalingam C wrote:

From: Matt Roper 

DG2 supports a 5th display output which the hardware refers to as "TC1,"
even though it isn't a Type-C output.  This behaves similarly to the TC1
on past platforms with just a couple minor differences:

* DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on
  ICP/TGP/ADP.
* DG2 doesn't need the hpd inversion setting that we had to use on DG1

v2:
 intel_ddi_init(dev_priv, PORT_TC1); [Matt]

Cc: Swathi Dhanavanthri 
Cc: Lucas De Marchi 
Cc: José Roberto de Souza 
Signed-off-by: Matt Roper 
Signed-off-by: Ramalingam C 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


Re: [PATCH v6 01/10] mm: add zone device coherent type memory support

2022-02-17 Thread Felix Kuehling

Am 2022-02-16 um 07:26 schrieb Jason Gunthorpe:

The other place that needs careful audit is all the callers using
vm_normal_page() - they must all be able to accept a ZONE_DEVICE page
if we don't set pte_devmap.


How much code are we talking about here? A quick search finds 26 
call-sites in 12 files in current master:


   fs/proc/task_mmu.c
   mm/hmm.c
   mm/gup.c
   mm/huge_memory.c (vm_normal_page_pmd)
   mm/khugepaged.c
   mm/madvise.c
   mm/mempolicy.c
   mm/memory.c
   mm/mlock.c
   mm/migrate.c
   mm/mprotect.c
   mm/memcontrol.c

I'm thinking of a more theoretical approach: Instead of auditing all 
users, I'd ask, what are the invariants that a vm_normal_page should 
have. Then check, whether our DEVICE_COHERENT pages satisfy them. But 
maybe the concept of a vm_normal_page isn't defined clearly enough for that.


That said, I think we (Alex and myself) made an implicit assumption from 
the start, that a DEVICE_COHERENT page should behave a lot like a normal 
page in terms of VMA mappings, even if we didn't know what that means in 
detail.


I can now at least name some differences between DEVICE_COHERENT and 
normal pages: how the memory is allocated, how data is migrated into 
DEVICE_COHERENT pages and that it can't be on any LRU list (because the 
lru list_head in struct page is aliased by pgmap and zone_device_data). 
Maybe I'll find more differences if I keep digging.


Regards,
  Felix




Jason


Re: [PATCH 1/4] dt-bindings: display: bridge: tc358867: Document DPI output support

2022-02-17 Thread Marek Vasut

On 2/3/22 13:23, Maxime Ripard wrote:

On Tue, Dec 07, 2021 at 06:32:38PM +0100, Marek Vasut wrote:

On 12/7/21 18:03, Laurent Pinchart wrote:

On Tue, Dec 07, 2021 at 05:47:29PM +0100, Marek Vasut wrote:

On 12/7/21 17:43, Laurent Pinchart wrote:

[...]


diff --git 
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml 
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
index f1541cc05297..5cfda6f2ba69 100644
--- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml
@@ -61,8 +61,8 @@ properties:
  port@1:
$ref: /schemas/graph.yaml#/properties/port
description: |
-DPI input port. The remote endpoint phandle should be a
-reference to a valid DPI output endpoint node
+DPI input/output port. The remote endpoint phandle should be a
+reference to a valid DPI output or input endpoint node.


I assume the mode of operation (input or output) will be fixed for a
given hardware design. Isn't this something that should be recorded in
DT ? It would simplify configuration of the device in the driver.


Currently the configuration (DSI-to-DPI / DPI-to-eDP) is inferred from
the presence of DPI panel. If DPI panel present, DSI-to-DPI, else,
DPI-to-eDP.


I've had a look at the driver side, and it seems to complicate things
quite a bit. It seems that specifying the mode of operation explicitly
in DT could make software implementations quite a bit simpler.


Do you have any specific suggestion ? I explored multiple options while
writing that DSI-to-DPI driver code, this one was the simplest and least
redundant one.


Can we leverage the bus-type property of endpoints?


We could, but should we really add a property only for the sake of 
adding a property ? The driver can figure out whether this endpoint is 
DSI-input or DSI-output without such a new property.


Now that I look at the datasheet, the logic can be even simpler:

- If port@0 not connected
  scanout -> port@1 (DPI input) -> port@2 (eDP output) -> panel

- If port@1 not connected
  scanout -> port@0 (DSI input) -> port@2 (eDP output) -> panel

- If port@2 not connected
  scanout -> port@0 (DSI input) -> port@1 (DPI output) -> panel

So with this kind of test in the driver, the driver can determine how 
the TC bridge is wired, without any extra props.


Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface

2022-02-17 Thread kernel test robot
Hi Andi,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next 
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc4 
next-20220217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/Introduce-multitile-support/20220217-224547
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-defconfig 
(https://download.01.org/0day-ci/archive/20220218/202202180400.ppkeh3z4-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/b358d991c154dc27fa4ef2fc99f8819f4f3e97e7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Andi-Shyti/Introduce-multitile-support/20220217-224547
git checkout b358d991c154dc27fa4ef2fc99f8819f4f3e97e7
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   ld: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o: in function 
`sysfs_gt_attribute_r_func.isra.0':
>> intel_gt_sysfs_pm.c:(.text+0x1b2): undefined reference to `__divdi3'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


Re: [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset

2022-02-17 Thread Lucas De Marchi

On Wed, Feb 16, 2022 at 09:36:02AM +, Hogander, Jouni wrote:

On Wed, 2022-02-16 at 10:50 +0200, Ville Syrjälä wrote:

On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote:
> From: Jouni Högander 
>
> Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E
> port. Correct offset is 0x64C14.

Why is it PHY_E and not PHY_F?


This is a valid question. It seems we have followed intel_phy_is_snps()
here:

// snip
else if (IS_DG2(dev_priv))
/*
 * All four "combo" ports and the TC1 port (PHY E) use
 * Synopsis PHYs.
 */
return phy <= PHY_E;
// snip


And this is actually the bug that we had. We wouldn't need to bring the
incomplete support for the 5th port if this single had changed:  it's
often preferred to prepare the driver first and enable the port/phy as
the last step:

-   return phy <= PHY_E;
+   return phy <= PHY_D;

With possibly a change in the commit above. Because in
drivers/gpu/drm/i915/display/intel_snps_phy.c we do:

intel_snps_phy_wait_for_calibration()
{
...
for_each_phy_masked(phy, ~0) {
if (!intel_phy_is_snps(i915, phy))
continue;
...
}

Relying on intel_phy_is_snps() to mask out the unavailable phys.

However, since now we almost have the extra port wired up, I'm not going
to push back on it. Let's just add a comment on the commit message.
And since going with this approach is also acked by Ville who preferred
to contain the additional mapping inside intel_phy_snps.c:

Reviewed-by: Lucas De Marchi 

Lucas De Marchi




According to spec port E is "No connection". Better place to fix this
could be intel_phy_is_snps() itself?



> Fix this by handling PHY_E port seprately.
>
> Signed-off-by: Matt Roper 
> Signed-off-by: Jouni Högander 
> Signed-off-by: Ramalingam C 
> ---
>  drivers/gpu/drm/i915/display/intel_snps_phy.c | 2 +-
>  drivers/gpu/drm/i915/i915_reg.h   | 6 --
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index c60575cb5368..f08061c748b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -32,7 +32,7 @@ void intel_snps_phy_wait_for_calibration(struct
> drm_i915_private *i915)
>if (!intel_phy_is_snps(i915, phy))
>continue;
>
> -  if (intel_de_wait_for_clear(i915, ICL_PHY_MISC(phy),
> +  if (intel_de_wait_for_clear(i915, DG2_PHY_MISC(phy),
>DG2_PHY_DP_TX_ACK_MASK,
> 25))
>drm_err(>drm, "SNPS PHY %c failed to
> calibrate after 25ms.\n",
>phy);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 4d12abb2d7ff..354c25f483cb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9559,8 +9559,10 @@ enum skl_power_gate {
>
>  #define _ICL_PHY_MISC_A   0x64C00
>  #define _ICL_PHY_MISC_B   0x64C04
> -#define ICL_PHY_MISC(port)_MMIO_PORT(port, _ICL_PHY_MISC_A, \
> -   _ICL_PHY_MISC_B)
> +#define _DG2_PHY_MISC_TC1 0x64C14 /* TC1="PHY E" but offset as if
> "PHY F" */
> +#define ICL_PHY_MISC(port)_MMIO_PORT(port, _ICL_PHY_MISC_A,
> _ICL_PHY_MISC_B)
> +#define DG2_PHY_MISC(port)((port) == PHY_E ?
> _MMIO(_DG2_PHY_MISC_TC1) : \
> +   ICL_PHY_MISC(port))
>  #define  ICL_PHY_MISC_MUX_DDID(1 << 28)
>  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN (1 << 23)
>  #define  DG2_PHY_DP_TX_ACK_MASK   REG_GENMASK(23,
> 20)
> --
> 2.20.1


BR,

Jouni Högander


Re: [PATCH v3 05/12] PCI: Detect root port of internal USB4 devices by `usb4-host-interface`

2022-02-17 Thread Bjorn Helgaas
On Mon, Feb 14, 2022 at 12:56:58PM +0200, Mika Westerberg wrote:
> On Mon, Feb 14, 2022 at 09:52:02AM +0100, Lukas Wunner wrote:
> > On Mon, Feb 14, 2022 at 09:34:26AM +0200, Mika Westerberg wrote:
> > > On Fri, Feb 11, 2022 at 03:45:46PM -0600, Bjorn Helgaas wrote:
> > > > My expectation is that "USB" (like "PCI" and "PCIe") tells me
> > > > something about how a device is electrically connected and how
> > > > software can operate it.  It doesn't really tell me anything about
> > > > whether those electrical connections are permanent, made through an
> > > > internal slot, or made through an external connector and cable.
> > > 
> > > It is used to identify "tunneled" ports (whether PCIe, USB 3.x or
> > > DisplayPort). Tunnels are created by software (in Linux it is the
> > > Thunderbolt driver) and are dynamic in nature. The USB4 links go over
> > > USB Type-C cable which also is something user can plug/unplug freely.
> > > 
> > > I would say it is reasonable expectation that anything behind these
> > > ports can be assumed as "removable".
> > 
> > USB gadgets may be soldered to the mainboard.  Those cannot be
> > unplugged freely.  It is common practice to solder USB Ethernet
> > or USB FTDI serial ports and nothing's preventing a vendor to solder
> > USB4/Thunderbolt gadgets.
> 
> Right, that's why I say it is "reasonable expectation" that anything
> behind these ports can be assumed "removable" :) Of course they don't
> have to be but if we assume that in the driver where this actually
> matters we should be on the safe side, no?

Spec citations help maintain things over the long term.  Reasonable
expectations that are part of today's folklore but are not written
down and shared leads to things that work today but not tomorrow.

Bjorn


Re: [PATCH 0/8] drm: Add support for low-color frame buffer formats

2022-02-17 Thread Sam Ravnborg
Hi Geert,

On Tue, Feb 15, 2022 at 05:52:18PM +0100, Geert Uytterhoeven wrote:
>   Hi all,
> 
> A long outstanding issue with the DRM subsystem has been the lack of
> support for low-color displays, as used typically on older desktop
> systems and small embedded displays.

This is one of the pieces missing for a long time - great to see
something done here. Thanks Geert!

Sam


Re: [PATCH 8/8] drm/fourcc: Add DRM_FORMAT_D1

2022-02-17 Thread Sam Ravnborg
Hi Geert,

> 
> C1 is color-indexed, which can be any two colors.
> R1 is light-on-dark.
> D1 is dark-on-light.

It would be nice to have this explained in the fourcc.h file,
preferably with a little more verbosity than the current explanations.

Sam


Re: [PATCH 2/8] drm/fb-helper: Add support for DRM_FORMAT_C[124]

2022-02-17 Thread Sam Ravnborg
Hi Geert,

> > > + switch (fb->format->depth) {
> >
> > The depth field is deprecated. It's probably better to use
> > fb->format->format and test against 4CC codes.
> 
> The reason I checked for depth instead of a 4CC code is that the only
> thing that matters here is the number of bits per pixel.  Hence this
> function won't need any changes to support R1, R2, R4, and D1 later.
> When we get here, we already know that we are using a format that
> is supported by the fbdev helper code, and thus passed the 4CC
> checks elsewhere.
> 
> Alternatively, we could introduce drm_format_info_bpp() earlier in
> the series, and use that?

The drm_format_info_bpp() is very descriptive, so yes it would be good to use
it here also.

Sam


[PATCH v2 1/3] drm_cache: Add logic for wbvind_on_all_cpus

2022-02-17 Thread Michael Cheng
Add logic for wbvind_on_all_cpus for non-x86 platforms.

v2(Michael Cheng): Change logic to if platform is not x86, then
   we add pr_warn for calling wbvind_on_all_cpus.

Signed-off-by: Michael Cheng 
---
 drivers/gpu/drm/drm_cache.c | 2 --
 include/drm/drm_cache.h | 6 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 66597e411764..722e3931d68a 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -40,8 +40,6 @@
 #define MEMCPY_BOUNCE_SIZE 128
 
 #if defined(CONFIG_X86)
-#include 
-
 /*
  * clflushopt is an unordered instruction which needs fencing with mfence or
  * sfence to avoid ordering issues.  For drm_clflush_page this fencing happens
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index 22deb216b59c..24fcf6be1419 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -34,6 +34,12 @@
 #define _DRM_CACHE_H_
 
 #include 
+#include 
+
+#if !defined(CONFIG_x86)
+#define wbinvd_on_all_cpus() \
+   pr_warn("Missing cache flush in %s\n", __func__)
+#endif
 
 struct iosys_map;
 
-- 
2.25.1



[PATCH v2 2/3] drm/i915/gem: Remove logic for wbinvd_on_all_cpus

2022-02-17 Thread Michael Cheng
drm_cache.h now handles calls to wbinvd_on_all_cpus.

Signed-off-by: Michael Cheng 
---
 drivers/gpu/drm/i915/gem/i915_gem_pm.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 00359ec9d58b..ee4783e4d135 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -13,12 +13,7 @@
 #include "i915_driver.h"
 #include "i915_drv.h"
 
-#if defined(CONFIG_X86)
-#include 
-#else
-#define wbinvd_on_all_cpus() \
-   pr_warn(DRIVER_NAME ": Missing cache flush in %s\n", __func__)
-#endif
+#include 
 
 void i915_gem_suspend(struct drm_i915_private *i915)
 {
-- 
2.25.1



[PATCH v2 3/3] drm/i915/: Add drm_cache.h

2022-02-17 Thread Michael Cheng
Add drm_cache.h to additionals files that calls wbinvd_on_all_cpus and
remove un-needed header files.

Signed-off-by: Michael Cheng 
---
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 13917231ae81..edb0ebbb089c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include "gem/i915_gem_dmabuf.h"
 #include "i915_drv.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 8850d4e0f9cc..dac62e3ba142 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -7,10 +7,10 @@
 #include 
 
 #include 
-#include 
 
 #include 
 #include 
+#include 
 
 #include "gem/i915_gem_lmem.h"
 
-- 
2.25.1



[PATCH v2 0/3] Move #define wbvind_on_all_cpus

2022-02-17 Thread Michael Cheng
This series moves the logic for wbvind_on_all_cpus to drm_cache. The logic 
changes a little here, if platform is not x86 then we throw out a warning
for when wbvind_on_all_cpus is being called. 

v2(Michael Cheng): Move and redo logic for wbvind_on_all_cpus. Also
   add drm_cache.h where the function is being called and 
   remove uneeded header files.

Michael Cheng (3):
  drm_cache: Add logic for wbvind_on_all_cpus
  drm/i915/gem: Remove logic for wbinvd_on_all_cpus
  drm/i915/: Add drm_cache.h

 drivers/gpu/drm/drm_cache.c| 2 --
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
 drivers/gpu/drm/i915/gem/i915_gem_pm.c | 7 +--
 drivers/gpu/drm/i915/gt/intel_ggtt.c   | 2 +-
 include/drm/drm_cache.h| 6 ++
 5 files changed, 9 insertions(+), 10 deletions(-)

-- 
2.25.1



Re: [PATCH v7 1/4] drm/msm/dpu: revise timing engine programming to support widebus feature

2022-02-17 Thread Kuogee Hsieh



On 2/16/2022 10:34 PM, Dmitry Baryshkov wrote:

On 17/02/2022 01:05, Kuogee Hsieh wrote:
Widebus feature will transmit two pixel data per pixel clock to 
interface.

Timing engine provides driving force for this purpose. This patch base
on HPG (Hardware Programming Guide) to revise timing engine register
setting to accommodate both widebus and non widebus application. Also
horizontal width parameters need to be reduced by half since two pixel
data are clocked out per pixel clock when widebus feature enabled.

Widebus can be enabled individually at DP. However at DSI, widebus have
to be enabled along with DSC to achieve pixel clock rate be scaled down
with same ratio as compression ratio when 10 bits per source component.
Therefore this patch add no supports of DSI related widebus and 
compression.


Changes in v2:
-- remove compression related code from timing
-- remove op_info from  struct msm_drm_private
-- remove unnecessary wide_bus_en variables
-- pass wide_bus_en into timing configuration by struct msm_dp

Changes in v3:
-- split patch into 3 patches

Changes in v4:
-- rework timing engine to not interfere with dsi/hdmi
-- cover both widebus and compression

Changes in v5:
-- remove supports of DSI widebus and compression

Changes in v7:
-- split this patch into 3 patches
-- add Tested-by

Signed-off-by: Kuogee Hsieh 
Tested-by: Bjorn Andersson 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c    | 10 
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h    |  2 +
  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   | 14 ++
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c    | 55 
--

  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h    |  2 +
  5 files changed, 68 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c

index 1e648db..2b2dbb7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -208,6 +208,8 @@ struct dpu_encoder_virt {
    u32 idle_timeout;
  +    bool wide_bus_en;
+
  struct msm_dp *dp;
  };
  @@ -217,6 +219,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
  15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
  };
  +
+bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc)
+{
+    struct dpu_encoder_virt *dpu_enc = to_dpu_encoder_virt(drm_enc);
+
+    return dpu_enc->wide_bus_en;
+}
+
  static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong 
*hw_pp, unsigned bpc)

  {
  struct dpu_hw_dither_cfg dither_cfg = { 0 };
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h

index e241914..0d73550 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -168,4 +168,6 @@ int dpu_encoder_get_linecount(struct drm_encoder 
*drm_enc);

   */
  int dpu_encoder_get_vsync_count(struct drm_encoder *drm_enc);
  +bool dpu_encoder_is_widebus_enabled(struct drm_encoder *drm_enc);
+
  #endif /* __DPU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c

index ddd9d89..04ac2dc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -110,6 +110,20 @@ static void drm_mode_to_intf_timing_params(
  timing->v_back_porch += timing->v_front_porch;
  timing->v_front_porch = 0;
  }
+
+    timing->wide_bus_en = 
dpu_encoder_is_widebus_enabled(phys_enc->parent);

+
+    /*
+ * for DP, divide the horizonal parameters by 2 when
+ * widebus is enabled
+ */
+    if (phys_enc->hw_intf->cap->type == INTF_DP && 
timing->wide_bus_en) {

+    timing->width = timing->width >> 1;
+    timing->xres = timing->xres >> 1;
+    timing->h_back_porch = timing->h_back_porch >> 1;
+    timing->h_front_porch = timing->h_front_porch >> 1;
+    timing->hsync_pulse_width = timing->hsync_pulse_width >> 1;
+    }
  }
    static u32 get_horizontal_total(const struct intf_timing_params 
*timing)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c

index 116e2b5..b68e696 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -33,6 +33,7 @@
  #define INTF_TP_COLOR1  0x05C
  #define INTF_CONFIG2    0x060
  #define INTF_DISPLAY_DATA_HCTL  0x064
+#define INTF_ACTIVE_DATA_HCTL   0x068
  #define INTF_FRAME_LINE_COUNT_EN    0x0A8
  #define INTF_FRAME_COUNT    0x0AC
  #define   INTF_LINE_COUNT   0x0B0
@@ -90,15 +91,23 @@ static void 
dpu_hw_intf_setup_timing_engine(struct dpu_hw_intf *ctx,

  u32 hsync_period, vsync_period;
  u32 display_v_start, display_v_end;
  u32 hsync_start_x, hsync_end_x;
+    u32 hsync_data_start_x, hsync_data_end_x;
  

[Important!] 2022 X.Org Foundation Membership deadline for voting in the election

2022-02-17 Thread Lyude Paul
The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding instructions on the nomination process to membership in the
near future.

Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
upcoming election is March 17th 2022 at 23:59 UTC.

If you are interested in joining the X.Org Foundation or in renewing
your membership, please visit the membership system site at:

https://members.x.org/

You can find the current election schedule here:

https://www.x.org/wiki/BoardOfDirectors/Elections/2022/

Lyude Paul,
On behalf of the X.Org elections committee




Re: [REPOST PATCH v4 01/13] drm/msm/dsi: add support for dsc data

2022-02-17 Thread Abhinav Kumar




On 2/10/2022 2:34 AM, Vinod Koul wrote:

Display Stream Compression (DSC) parameters need to be calculated. Add
helpers and struct msm_display_dsc_config in msm_drv for this
msm_display_dsc_config uses drm_dsc_config for DSC parameters.

Signed-off-by: Vinod Koul 


As we spoke during the sync up, since migration to the upstream API has 
been agreed upon to be done later, this change LGTM. Hence,


Reviewed-by: Abhinav Kumar 


---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 132 +
  drivers/gpu/drm/msm/msm_drv.h  |  15 
  2 files changed, 147 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 6b3ced4aaaf5..27553194f9fa 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -31,6 +31,8 @@
  
  #define DSI_RESET_TOGGLE_DELAY_MS 20
  
+static int dsi_populate_dsc_params(struct msm_display_dsc_config *dsc);

+
  static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
  {
u32 ver;
@@ -157,6 +159,7 @@ struct msm_dsi_host {
struct regmap *sfpb;
  
  	struct drm_display_mode *mode;

+   struct msm_display_dsc_config *dsc;
  
  	/* connected device info */

struct device_node *device_node;
@@ -1718,6 +1721,135 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host 
*msm_host,
return -EINVAL;
  }
  
+static u32 dsi_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {

+   0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54, 0x62,
+   0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
+};
+
+/* only 8bpc, 8bpp added */
+static char min_qp[DSC_NUM_BUF_RANGES] = {
+   0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13
+};
+
+static char max_qp[DSC_NUM_BUF_RANGES] = {
+   4, 4, 5, 6, 7, 7, 7, 8, 9, 10, 11, 12, 13, 13, 15
+};
+
+static char bpg_offset[DSC_NUM_BUF_RANGES] = {
+   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
+};
+
+static int dsi_populate_dsc_params(struct msm_display_dsc_config *dsc)
+{
+   int mux_words_size;
+   int groups_per_line, groups_total;
+   int min_rate_buffer_size;
+   int hrd_delay;
+   int pre_num_extra_mux_bits, num_extra_mux_bits;
+   int slice_bits;
+   int target_bpp_x16;
+   int data;
+   int final_value, final_scale;
+   int i;
+
+   dsc->drm->rc_model_size = 8192;
+   dsc->drm->first_line_bpg_offset = 12;
+   dsc->drm->rc_edge_factor = 6;
+   dsc->drm->rc_tgt_offset_high = 3;
+   dsc->drm->rc_tgt_offset_low = 3;
+   dsc->drm->simple_422 = 0;
+   dsc->drm->convert_rgb = 1;
+   dsc->drm->vbr_enable = 0;
+
+   /* handle only bpp = bpc = 8 */
+   for (i = 0; i < DSC_NUM_BUF_RANGES - 1 ; i++)
+   dsc->drm->rc_buf_thresh[i] = dsi_dsc_rc_buf_thresh[i];
+
+   for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
+   dsc->drm->rc_range_params[i].range_min_qp = min_qp[i];
+   dsc->drm->rc_range_params[i].range_max_qp = max_qp[i];
+   dsc->drm->rc_range_params[i].range_bpg_offset = bpg_offset[i];
+   }
+
+   dsc->drm->initial_offset = 6144; /* Not bpp 12 */
+   if (dsc->drm->bits_per_pixel != 8)
+   dsc->drm->initial_offset = 2048;  /* bpp = 12 */
+
+   mux_words_size = 48;/* bpc == 8/10 */
+   if (dsc->drm->bits_per_component == 12)
+   mux_words_size = 64;
+
+   dsc->drm->initial_xmit_delay = 512;
+   dsc->drm->initial_scale_value = 32;
+   dsc->drm->first_line_bpg_offset = 12;
+   dsc->drm->line_buf_depth = dsc->drm->bits_per_component + 1;
+
+   /* bpc 8 */
+   dsc->drm->flatness_min_qp = 3;
+   dsc->drm->flatness_max_qp = 12;
+   dsc->det_thresh_flatness = 7 + 2 * (dsc->drm->bits_per_component - 8);
+   dsc->drm->rc_quant_incr_limit0 = 11;
+   dsc->drm->rc_quant_incr_limit1 = 11;
+   dsc->drm->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+
+   /* FIXME: need to call drm_dsc_compute_rc_parameters() so that rest of
+* params are calculated
+*/
+   dsc->slice_last_group_size = 3 - (dsc->drm->slice_width % 3);
+   groups_per_line = DIV_ROUND_UP(dsc->drm->slice_width, 3);
+   dsc->drm->slice_chunk_size = dsc->drm->slice_width * 
dsc->drm->bits_per_pixel / 8;
+   if ((dsc->drm->slice_width * dsc->drm->bits_per_pixel) % 8)
+   dsc->drm->slice_chunk_size++;
+
+   /* rbs-min */
+   min_rate_buffer_size =  dsc->drm->rc_model_size - 
dsc->drm->initial_offset +
+   dsc->drm->initial_xmit_delay * 
dsc->drm->bits_per_pixel +
+   groups_per_line * 
dsc->drm->first_line_bpg_offset;
+
+   hrd_delay = DIV_ROUND_UP(min_rate_buffer_size, 
dsc->drm->bits_per_pixel);
+
+   dsc->drm->initial_dec_delay = hrd_delay - dsc->drm->initial_xmit_delay;
+
+   dsc->drm->initial_scale_value = 8 * dsc->drm->rc_model_size /
+  (dsc->drm->rc_model_size - 

Re: [PATCH libdrm v2 00/25] Update Tegra support

2022-02-17 Thread Dmitry Osipenko
17.02.2022 22:16, Thierry Reding пишет:
> From: Thierry Reding 
> 
> Hi all,
> 
> this is the userspace part of the kernel patches that were recently
> merged into drm-next:
> 
>   https://patchwork.freedesktop.org/series/92378/
> 
> The goal is to provide a userspace implementation of the UAPI exposed by
> the kernel and show its usage in some test programs that can also be
> used for basic sanity testing. More complete userspace implementations
> are available here:
> 
>   * https://github.com/cyndis/vaapi-tegra-driver
>   * https://github.com/grate-driver/xf86-video-opentegra
>   * https://github.com/grate-driver/grate
> 
> Changes in v2:
> - implement vic_clear() as a helper using ->fill() (Michał Mirosław)
> - rebase and fix a couple of Meson errors/warnings
> 
> Thierry
> 
> Thierry Reding (25):
>   tegra: Indent according to .editorconfig
>   tegra: Remove unused IOCTL implementations
>   tegra: Extract common buffer object allocation code
>   tegra: Fix mmap() of GEM buffer objects
>   tegra: Add flink helpers
>   tegra: Add PRIME support helpers
>   tegra: Make API more consistent
>   tegra: Install tegra-openclose test
>   tegra: Update for new UABI
>   tegra: Include private.h in list of source files
>   tegra: Add channel APIs
>   tegra: Add job and push buffer APIs
>   tegra: Add syncpoint APIs
>   tests: tegra: Add helper library for tests
>   tests: tegra: Add gr2d-fill test
>   tests: tegra: Add syncpt-wait test
>   tests: tegra: Add syncpoint timeout test
>   tests: tegra: Add VIC support
>   tests: tegra: Add VIC 3.0 support
>   tests: tegra: Add VIC 4.0 support
>   tests: tegra: Add VIC 4.1 support
>   tests: tegra: Add VIC 4.2 support
>   tests: tegra: Add VIC clear test
>   tests: tegra: Add VIC blit test
>   tests: tegra: Add VIC flip test
> 
>  include/drm/tegra_drm.h  | 429 +++--
>  tegra/channel.c  | 195 
>  tegra/job.c  | 187 +++
>  tegra/meson.build|   7 +-
>  tegra/private.h  |  85 -
>  tegra/pushbuf.c  | 184 +++
>  tegra/syncpt.c   | 101 ++
>  tegra/tegra-symbols.txt  |  27 +-
>  tegra/tegra.c| 386 +++---
>  tegra/tegra.h|  95 +-
>  tests/tegra/.gitignore   |   3 +-
>  tests/tegra/drm-test-tegra.c | 147 +
>  tests/tegra/drm-test-tegra.h |  55 
>  tests/tegra/drm-test.c   | 248 +++
>  tests/tegra/drm-test.h   |  72 +
>  tests/tegra/gr2d-fill.c  | 146 +
>  tests/tegra/host1x.h |  34 ++
>  tests/tegra/meson.build  |  88 +-
>  tests/tegra/openclose.c  |  52 +--
>  tests/tegra/syncpt-timeout.c | 163 ++
>  tests/tegra/syncpt-wait.c| 151 +
>  tests/tegra/vic-blit.c   | 333 +++
>  tests/tegra/vic-clear.c  | 173 ++
>  tests/tegra/vic-flip.c   | 333 +++
>  tests/tegra/vic.c| 184 +++
>  tests/tegra/vic.h| 181 +++
>  tests/tegra/vic30.c  | 458 +++
>  tests/tegra/vic30.h  | 439 ++
>  tests/tegra/vic40.c  | 370 ++
>  tests/tegra/vic40.h  | 285 +
>  tests/tegra/vic41.c  | 374 ++
>  tests/tegra/vic41.h  | 372 ++
>  tests/tegra/vic42.c  | 374 ++
>  tests/tegra/vic42.h  | 597 +++
>  34 files changed, 7068 insertions(+), 260 deletions(-)


Why do we need these tests in libdrm? Why not IGT?



[git pull] drm fixes for 5.17-rc5

2022-02-17 Thread Dave Airlie
Hi Linus,

Regular fixes for rc5, nothing really stands out, mostly some amdgpu
and i915 fixes with mediatek, radeon and some misc fixes.

Dave.

drm-fixes-2022-02-18:
drm fixes for 5.17-rc5

cma-helper:
- set VM_DONTEXPAND

atomic:
- error handling fix.

mediatek:
- fix probe defer loop with external bridge

amdgpu:
- Stable pstate clock fixes for Dimgrey Cavefish and Beige Goby
- S0ix SDMA fix
- Yellow Carp GPU reset fix

radeon:
- Backlight fix for iMac 12,1

i915:
- GVT kerneldoc cleanup.
- GVT Kconfig should depend on X86
- Prevent out of range access in SWSCI display code.
- Fix mbus join and dbuf slice config lookup.
- Fix inverted priority selection in the TTM backend.
- Fix FBC plane end Y offset check.
The following changes since commit 754e0b0e35608ed5206d6a67a791563c631cec07:

  Linux 5.17-rc4 (2022-02-13 12:13:30 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-02-18

for you to fetch changes up to 5666b610194705587807a1078753eadc007b9d79:

  Merge tag 'drm-intel-fixes-2022-02-17' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2022-02-18
05:44:45 +1000)


drm fixes for 5.17-rc5

cma-helper:
- set VM_DONTEXPAND

atomic:
- error handling fix.

mediatek:
- fix probe defer loop with external bridge

amdgpu:
- Stable pstate clock fixes for Dimgrey Cavefish and Beige Goby
- S0ix SDMA fix
- Yellow Carp GPU reset fix

radeon:
- Backlight fix for iMac 12,1

i915:
- GVT kerneldoc cleanup.
- GVT Kconfig should depend on X86
- Prevent out of range access in SWSCI display code.
- Fix mbus join and dbuf slice config lookup.
- Fix inverted priority selection in the TTM backend.
- Fix FBC plane end Y offset check.


AngeloGioacchino Del Regno (1):
  drm/mediatek: mtk_dsi: Avoid EPROBE_DEFER loop with external bridge

Dave Airlie (4):
  Merge tag 'mediatek-drm-fixes-5.17' of
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux
into drm-fixes
  Merge tag 'amd-drm-fixes-5.17-2022-02-16' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2022-02-17' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2022-02-17' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Evan Quan (1):
  drm/amd/pm: correct UMD pstate clocks for Dimgrey Cavefish and Beige Goby

Jani Nikula (1):
  drm/i915/opregion: check port number bounds for SWSCI display power state

Matthew Auld (1):
  drm/i915/ttm: tweak priority hint selection

Nicholas Bishop (1):
  drm/radeon: Fix backlight control on iMac 12,1

Rajib Mahapatra (1):
  drm/amdgpu: skipping SDMA hw_init and hw_fini for S0ix.

Randy Dunlap (1):
  drm/i915/gvt: clean up kernel-doc in gtt.c

Robin Murphy (1):
  drm/cma-helper: Set VM_DONTEXPAND for mmap

Siva Mullati (1):
  drm/i915/gvt: Make DRM_I915_GVT depend on X86

Tvrtko Ursulin (1):
  Merge tag 'gvt-fixes-2022-01-13' of
https://github.com/intel/gvt-linux into drm-intel-fixes

Ville Syrjälä (4):
  drm/i915: Fix dbuf slice config lookup
  drm/i915: Fix mbus join config lookup
  drm/i915/fbc: Fix the plane end Y offset check
  drm/atomic: Don't pollute crtc_state->mode_blob with error pointers

Yifan Zhang (1):
  drm/amd/pm: correct the sequence of sending gpu reset msg

 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |   8 +
 .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c|  26 +++-
 .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.h|   8 +
 .../gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c   |   9 +-
 drivers/gpu/drm/drm_atomic_uapi.c  |  14 +-
 drivers/gpu/drm/drm_gem_cma_helper.c   |   1 +
 drivers/gpu/drm/i915/Kconfig   |   1 +
 drivers/gpu/drm/i915/display/intel_fbc.c   |   3 +-
 drivers/gpu/drm/i915/display/intel_opregion.c  |  15 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c|   6 +-
 drivers/gpu/drm/i915/gvt/gtt.c |   4 +-
 drivers/gpu/drm/i915/intel_pm.c|   4 +-
 drivers/gpu/drm/mediatek/mtk_dsi.c | 167 +++--
 drivers/gpu/drm/radeon/atombios_encoders.c |   3 +-
 14 files changed, 158 insertions(+), 111 deletions(-)


Re: [PATCH v4 3/3] drm/msm/dp: replace DRM_DEBUG_DP marco with drm_dbg_dp

2022-02-17 Thread Kuogee Hsieh



On 2/17/2022 11:36 AM, Stephen Boyd wrote:

Quoting Kuogee Hsieh (2022-02-17 10:35:30)

Since DRM_DEBUG_DP is deprecated in favor of drm_dbg_dp(NULL, ...),
this patch replace all DRM_DEBUG_DP with drm_dbg_dp().

Changes in v4:
-- replace (strucr drm_dev *)NULL with drm_dev

Why can't the platform device be used?

#define drm_dbg_dp(drm, fmt, ...)   \

    drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DP, fmt, 
##__VA_ARGS__)


it looks for (drm)->dev (pointer)

struct platform_device {
    const char  *name;
    int id;
    bool    id_auto;
    struct device   dev  <== not an pointer here






X.Org Foundation GSoC mentors and projects

2022-02-17 Thread Trevor Woerner
Hi everyone,

Thanks to the amazing work Rodrigo does mentoring students (which
introduces them to GNU/Linux in general and X.Org/fd.o in particular) it
looks like we might have some potential GSoC candidates this year.

The last time we ran an X.Org GSoC, back in 2020, our amazing student,
Melissa, not only passed her project with flying colours, she continues on
in our community to this day as a co-admin of the VKMS driver. Several
other members of our community came to us via GSoC and are also still with
us making significant contributions.

Rodrigo and Melissa have put together a project they are excited to mentor:
https://www.x.org/wiki/AMDGPU2022/ . Daniel Vetter has also agreed to
mentor; perhaps a drm-related project. I've agreed to be the admin on
behalf of X.Org for our participation in GSoC.

If anyone else is interested in volunteering we would certainly appreciate
the help. We're always looking for mentors and project ideas. Our current
list of projects/mentors is found on our Ideas page:
https://www.x.org/wiki/SummerOfCodeIdeas/

If you have any questions or interest please get in touch!

Best regards,
Trevor


Re: [Intel-gfx] [PATCH v5 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces

2022-02-17 Thread kernel test robot
Hi Andi,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next 
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc4 
next-20220217]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/Introduce-multitile-support/20220217-224547
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a011 
(https://download.01.org/0day-ci/archive/20220218/202202180224.l042viyj-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/f1802e7224006bf4801fe56193bf5eb223a3f4d0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Andi-Shyti/Introduce-multitile-support/20220217-224547
git checkout f1802e7224006bf4801fe56193bf5eb223a3f4d0
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function 'act_freq_mhz_show':
>> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:250:20: error: implicit 
>> declaration of function 'sysfs_gt_attribute_r_func' 
>> [-Werror=implicit-function-declaration]
 250 |  s64 actual_freq = sysfs_gt_attribute_r_func(dev, attr,
 |^
   drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function 
'boost_freq_mhz_store':
>> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:318:9: error: implicit 
>> declaration of function 'sysfs_gt_attribute_w_func' 
>> [-Werror=implicit-function-declaration]
 318 |  return sysfs_gt_attribute_w_func(dev, attr,
 | ^
   cc1: some warnings being treated as errors


vim +/sysfs_gt_attribute_r_func +250 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c

   246  
   247  static ssize_t act_freq_mhz_show(struct device *dev,
   248   struct device_attribute *attr, char 
*buff)
   249  {
 > 250  s64 actual_freq = sysfs_gt_attribute_r_func(dev, attr,
   251  
__act_freq_mhz_show);
   252  
   253  return sysfs_emit(buff, "%u\n", (u32) actual_freq);
   254  }
   255  
   256  static s64 __cur_freq_mhz_show(struct intel_gt *gt)
   257  {
   258  return intel_rps_get_requested_frequency(>rps);
   259  }
   260  
   261  static ssize_t cur_freq_mhz_show(struct device *dev,
   262   struct device_attribute *attr, char 
*buff)
   263  {
   264  s64 cur_freq = sysfs_gt_attribute_r_func(dev, attr,
   265   __cur_freq_mhz_show);
   266  
   267  return sysfs_emit(buff, "%u\n", (u32) cur_freq);
   268  }
   269  
   270  static s64 __boost_freq_mhz_show(struct intel_gt *gt)
   271  {
   272  return intel_rps_get_boost_frequency(>rps);
   273  }
   274  
   275  static ssize_t boost_freq_mhz_show(struct device *dev,
   276 struct device_attribute *attr,
   277 char *buff)
   278  {
   279  s64 boost_freq = sysfs_gt_attribute_r_func(dev, attr,
   280 
__boost_freq_mhz_show);
   281  
   282  return sysfs_emit(buff, "%u\n", (u32) boost_freq);
   283  }
   284  
   285  static int __boost_freq_mhz_store(struct intel_gt *gt, u32 val)
   286  {
   287  struct intel_rps *rps = >rps;
   288  bool boost = false;
   289  
   290  /* Validate against (static) hardware limits */
   291  val = intel_freq_opcode(rps, val);
   292  if (val < rps->min_freq || val > rps->max_freq)
   293  return -EINVAL;
   294  
   295  mutex_lock(>lock);
   296  if (val != rps->boost_freq) {
   297  rps->boost_freq = val;
   298  boost = atomic_read(>num_waiters);
   299  }
   300  mutex_unlock(>lock);
   301  if (boost)
   302  schedule_work(>work);
   303  
   304  return 0;
   305  }
   306  
   307  static ssize_t boost_freq_mhz_store(struct device *dev,
   308  struct device_attribute *attr,
   309  const char *buff, size_t count)
   310  {
   311  ssize_t ret;
   312  u32 val;
   313  
   314

Re: [PATCH v9 1/4] drm/lsdc: add drm driver for loongson display controller

2022-02-17 Thread kernel test robot
Hi Sui,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on robh/for-next v5.17-rc4 next-20220217]
[cannot apply to mripard/sunxi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sui-Jingfeng/drm-lsdc-add-drm-driver-for-loongson-display-controller/20220217-185718
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: m68k-randconfig-r034-20220217 
(https://download.01.org/0day-ci/archive/20220217/202202172203.r8yqyawt-...@intel.com/config)
compiler: m68k-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/822d08dcd4408130e10897446cfdd640bcd53c8a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Sui-Jingfeng/drm-lsdc-add-drm-driver-for-loongson-display-controller/20220217-185718
git checkout 822d08dcd4408130e10897446cfdd640bcd53c8a
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross 
O=build_dir ARCH=m68k SHELL=/bin/bash drivers/gpu/drm/lsdc/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from include/linux/device.h:15,
from include/linux/pci.h:37,
from drivers/gpu/drm/lsdc/lsdc_drv.c:15:
   drivers/gpu/drm/lsdc/lsdc_drv.c: In function 'lsdc_vram_init':
>> include/drm/drm_print.h:425:39: warning: format '%llx' expects argument of 
>> type 'long long unsigned int', but argument 3 has type 'resource_size_t' 
>> {aka 'unsigned int'} [-Wformat=]
 425 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
 |   ^~~~
   include/linux/dev_printk.h:110:30: note: in definition of macro 
'dev_printk_index_wrap'
 110 | _p_func(dev, fmt, ##__VA_ARGS__);
   \
 |  ^~~
   include/linux/dev_printk.h:150:58: note: in expansion of macro 'dev_fmt'
 150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev, 
dev_fmt(fmt), ##__VA_ARGS__)
 |  ^~~
   include/drm/drm_print.h:425:9: note: in expansion of macro 'dev_info'
 425 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
 | ^~~~
   include/drm/drm_print.h:429:9: note: in expansion of macro '__drm_printk'
 429 | __drm_printk((drm), info,, fmt, ##__VA_ARGS__)
 | ^~~~
   drivers/gpu/drm/lsdc/lsdc_drv.c:518:9: note: in expansion of macro 'drm_info'
 518 | drm_info(ddev, "vram start: 0x%llx, size: %uMB\n", base, 
(u32)(size >> 20));
 | ^~~~
--
   In file included from drivers/gpu/drm/lsdc/lsdc_drv.h:17,
from drivers/gpu/drm/lsdc/lsdc_pll.c:14:
   drivers/gpu/drm/lsdc/lsdc_pll.c: In function 'lsdc_pixpll_setup':
>> drivers/gpu/drm/lsdc/lsdc_pll.c:169:62: warning: cast from pointer to 
>> integer of different size [-Wpointer-to-int-cast]
 169 | this->index, this->reg_base, this->reg_size, 
(u64)this->mmio);
 |  ^
   include/drm/drm_print.h:461:70: note: in definition of macro 'drm_dbg'
 461 | drm_dev_dbg((drm) ? (drm)->dev : NULL, DRM_UT_DRIVER, fmt, 
##__VA_ARGS__)
 |  
^~~


vim +425 include/drm/drm_print.h

02c9656b2f0d69 Haneen Mohammed   2017-10-17  385  
02c9656b2f0d69 Haneen Mohammed   2017-10-17  386  /**
b52817e9de06a3 Mauro Carvalho Chehab 2020-10-27  387   * DRM_DEV_DEBUG() - 
Debug output for generic drm code
02c9656b2f0d69 Haneen Mohammed   2017-10-17  388   *
306589856399e1 Douglas Anderson  2021-09-21  389   * NOTE: this is 
deprecated in favor of drm_dbg_core().
306589856399e1 Douglas Anderson  2021-09-21  390   *
091756bbb1a961 Haneen Mohammed   2017-10-17  391   * @dev: device pointer
091756bbb1a961 Haneen Mohammed   2017-10-17  392   * @fmt: printf() like 
format string.
02c9656b2f0d69 Haneen Mohammed   2017-10-17  393   */
db87086492581c Joe Perches   2018-03-16  394  #define 
DRM_DEV_DEBUG(dev, fmt, ...)  \
db87086492581c Joe Perches   2018-03-16  395drm_dev_dbg(dev, 
DRM_UT_CORE, fmt, 

Re: [PATCH v9 1/4] drm/lsdc: add drm driver for loongson display controller

2022-02-17 Thread kernel test robot
Hi Sui,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on robh/for-next v5.17-rc4 next-20220217]
[cannot apply to mripard/sunxi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sui-Jingfeng/drm-lsdc-add-drm-driver-for-loongson-display-controller/20220217-185718
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: csky-randconfig-s032-20220217 
(https://download.01.org/0day-ci/archive/20220218/202202180117.mokypazs-...@intel.com/config)
compiler: csky-linux-gcc (GCC) 11.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-dirty
# 
https://github.com/0day-ci/linux/commit/822d08dcd4408130e10897446cfdd640bcd53c8a
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Sui-Jingfeng/drm-lsdc-add-drm-driver-for-loongson-display-controller/20220217-185718
git checkout 822d08dcd4408130e10897446cfdd640bcd53c8a
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=csky 
SHELL=/bin/bash drivers/gpu/drm/lsdc/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/lsdc/lsdc_pll.c:168:9: sparse: sparse: cast removes address 
>> space '__iomem' of expression
   drivers/gpu/drm/lsdc/lsdc_pll.c: note: in included file (through 
arch/csky/include/asm/io.h, include/linux/io.h, include/linux/irq.h, ...):
   include/asm-generic/io.h:267:16: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:299:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:299:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:299:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:267:16: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:299:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:299:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:299:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:267:16: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:299:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:299:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:299:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:267:16: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:299:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:299:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:299:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:267:16: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:299:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:299:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:299:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:267:16: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:299:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:299:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:299:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:267:16: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:299:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:299:22: sparse: expected unsig

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix for PHY_MISC_TC1 offset

2022-02-17 Thread Lucas De Marchi

On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote:

From: Jouni Högander 

Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E
port. Correct offset is 0x64C14.

Fix this by handling PHY_E port seprately.


order of the patch here is wrong. This patch should come before
the patch initializing the 5th port. Then the commit message is not
a fix.

This can be done while applying since it's more an order to avoid
breaking the tree.

Lucas De Marchi


Re: [PATCH v4 3/3] drm/msm/dp: replace DRM_DEBUG_DP marco with drm_dbg_dp

2022-02-17 Thread Stephen Boyd
Quoting Kuogee Hsieh (2022-02-17 10:35:30)
> Since DRM_DEBUG_DP is deprecated in favor of drm_dbg_dp(NULL, ...),
> this patch replace all DRM_DEBUG_DP with drm_dbg_dp().
>
> Changes in v4:
> -- replace (strucr drm_dev *)NULL with drm_dev

Why can't the platform device be used?


Re: [Intel-gfx] [PATCH 2/3] drm/i915/dg2: Drop 38.4 MHz MPLLB tables

2022-02-17 Thread Lucas De Marchi

On Tue, Feb 15, 2022 at 11:21:53AM +0530, Ramalingam C wrote:

From: Matt Roper 

Our early understanding of DG2 was incorrect; since the 5th display
isn't actually a Type-C output, 38.4 MHz input clocks are never used on
this platform and we can drop the corresponding MPLLB tables.

Cc: Anusha Srivatsa 
Cc: José Roberto de Souza 
Signed-off-by: Matt Roper 
Signed-off-by: Ramalingam C 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi



---
drivers/gpu/drm/i915/display/intel_snps_phy.c | 208 +-
1 file changed, 1 insertion(+), 207 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c 
b/drivers/gpu/drm/i915/display/intel_snps_phy.c
index 8573a458811a..c60575cb5368 100644
--- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
@@ -250,197 +250,6 @@ static const struct intel_mpllb_state * const 
dg2_dp_100_tables[] = {
NULL,
};

-/*
- * Basic DP link rates with 38.4 MHz reference clock.
- */
-
-static const struct intel_mpllb_state dg2_dp_rbr_38_4 = {
-   .clock = 162000,
-   .ref_control =
-   REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
-   .mpllb_cp =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
-   .mpllb_div =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 2) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 2),
-   .mpllb_div2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 304),
-   .mpllb_fracn1 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
-   .mpllb_fracn2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 49152),
-};
-
-static const struct intel_mpllb_state dg2_dp_hbr1_38_4 = {
-   .clock = 27,
-   .ref_control =
-   REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
-   .mpllb_cp =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
-   .mpllb_div =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_TX_CLK_DIV, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3),
-   .mpllb_div2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 248),
-   .mpllb_fracn1 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
-   .mpllb_fracn2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 40960),
-};
-
-static const struct intel_mpllb_state dg2_dp_hbr2_38_4 = {
-   .clock = 54,
-   .ref_control =
-   REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
-   .mpllb_cp =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 5) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 25) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP_GS, 127),
-   .mpllb_div =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_DIV5_CLK_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_PMIX_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_V2I, 2) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FREQ_VCO, 3),
-   .mpllb_div2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_REF_CLK_DIV, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_MULTIPLIER, 248),
-   .mpllb_fracn1 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_CGG_UPDATE_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_EN, 1) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_DEN, 1),
-   .mpllb_fracn2 =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_FRACN_QUOT, 40960),
-};
-
-static const struct intel_mpllb_state dg2_dp_hbr3_38_4 = {
-   .clock = 81,
-   .ref_control =
-   REG_FIELD_PREP(SNPS_PHY_REF_CONTROL_REF_RANGE, 1),
-   .mpllb_cp =
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT, 6) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_PROP, 26) |
-   REG_FIELD_PREP(SNPS_PHY_MPLLB_CP_INT_GS, 65) 

[PATCH libdrm v2 25/25] tests: tegra: Add VIC flip test

2022-02-17 Thread Thierry Reding
From: Thierry Reding 

This test will attempt to use the VIC to blit one surface to another
and perform a vertical flip.

Signed-off-by: Thierry Reding 
---
 tests/tegra/meson.build |   9 ++
 tests/tegra/vic-flip.c  | 333 
 2 files changed, 342 insertions(+)
 create mode 100644 tests/tegra/vic-flip.c

diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
index 3cccbf64ecf4..26a32e868593 100644
--- a/tests/tegra/meson.build
+++ b/tests/tegra/meson.build
@@ -100,3 +100,12 @@ vic_blit = executable(
   link_with : [libdrm, libdrm_tegra, libdrm_test, libdrm_test_tegra],
   install : with_install_tests,
 )
+
+vic_flip = executable(
+  'tegra-vic-flip',
+  files('vic-flip.c'),
+  include_directories : [inc_root, inc_drm, inc_tegra],
+  c_args : libdrm_c_args,
+  link_with : [libdrm, libdrm_tegra, libdrm_test, libdrm_test_tegra],
+  install : with_install_tests,
+)
diff --git a/tests/tegra/vic-flip.c b/tests/tegra/vic-flip.c
new file mode 100644
index ..e94336be1697
--- /dev/null
+++ b/tests/tegra/vic-flip.c
@@ -0,0 +1,333 @@
+/*
+ * Copyright © 2018 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tegra.h"
+
+#include "host1x.h"
+#include "vic.h"
+
+/* clear output image to red */
+static int clear(struct vic *vic, struct drm_tegra_channel *channel,
+ struct vic_image *output)
+{
+struct drm_tegra_pushbuf *pushbuf;
+struct drm_tegra_job *job;
+uint32_t *ptr;
+int err;
+
+err = drm_tegra_job_new(channel, );
+if (err < 0) {
+fprintf(stderr, "failed to create job: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_job_get_pushbuf(job, );
+if (err < 0) {
+fprintf(stderr, "failed to create push buffer: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_pushbuf_begin(pushbuf, 32, );
+if (err < 0) {
+fprintf(stderr, "failed to prepare push buffer: %s\n", strerror(-err));
+return err;
+}
+
+err = vic_clear(vic, output, 1023, 0, 0, 1023);
+if (err < 0) {
+fprintf(stderr, "failed to clear surface: %s\n", strerror(-err));
+return err;
+}
+
+err = vic->ops->execute(vic, pushbuf, , output, NULL, 0);
+if (err < 0) {
+fprintf(stderr, "failed to execute operation: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_pushbuf_sync_cond(pushbuf, , vic->syncpt,
+  DRM_TEGRA_SYNC_COND_OP_DONE);
+if (err < 0) {
+fprintf(stderr, "failed to push syncpoint: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_pushbuf_end(pushbuf, ptr);
+if (err < 0) {
+fprintf(stderr, "failed to update push buffer: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_job_submit(job, NULL);
+if (err < 0) {
+fprintf(stderr, "failed to submit job: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_job_wait(job, 10);
+if (err < 0) {
+fprintf(stderr, "failed to wait for job: %s\n", strerror(-err));
+return err;
+}
+
+drm_tegra_job_free(job);
+
+return 0;
+}
+
+/* fill bottom half of image to blue */
+static int fill(struct vic *vic, struct drm_tegra_channel *channel,
+struct vic_image *output)
+{
+struct drm_tegra_pushbuf *pushbuf;
+struct drm_tegra_job *job;
+uint32_t *ptr;
+int err;
+
+err = drm_tegra_job_new(channel, );
+if (err < 0) {
+fprintf(stderr, "failed to create job: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_job_get_pushbuf(job, );
+if (err < 0) {
+fprintf(stderr, "failed to create push buffer: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_pushbuf_begin(pushbuf, 32, );
+if (err < 

[PATCH libdrm v2 24/25] tests: tegra: Add VIC blit test

2022-02-17 Thread Thierry Reding
From: Thierry Reding 

This test will attempt to use the VIC to blit from one surface to
another.

Signed-off-by: Thierry Reding 
---
 tests/tegra/meson.build |   9 ++
 tests/tegra/vic-blit.c  | 333 
 2 files changed, 342 insertions(+)
 create mode 100644 tests/tegra/vic-blit.c

diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
index c7bf35899780..3cccbf64ecf4 100644
--- a/tests/tegra/meson.build
+++ b/tests/tegra/meson.build
@@ -91,3 +91,12 @@ vic_clear = executable(
   link_with : [libdrm, libdrm_tegra, libdrm_test, libdrm_test_tegra],
   install : with_install_tests,
 )
+
+vic_blit = executable(
+  'tegra-vic-blit',
+  files('vic-blit.c'),
+  include_directories : [inc_root, inc_drm, inc_tegra],
+  c_args : libdrm_c_args,
+  link_with : [libdrm, libdrm_tegra, libdrm_test, libdrm_test_tegra],
+  install : with_install_tests,
+)
diff --git a/tests/tegra/vic-blit.c b/tests/tegra/vic-blit.c
new file mode 100644
index ..7baf9e7a0cc1
--- /dev/null
+++ b/tests/tegra/vic-blit.c
@@ -0,0 +1,333 @@
+/*
+ * Copyright © 2018 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tegra.h"
+
+#include "host1x.h"
+#include "vic.h"
+
+/* clear output image to red */
+static int clear(struct vic *vic, struct drm_tegra_channel *channel,
+ struct vic_image *output)
+{
+struct drm_tegra_pushbuf *pushbuf;
+struct drm_tegra_job *job;
+uint32_t *ptr;
+int err;
+
+err = drm_tegra_job_new(channel, );
+if (err < 0) {
+fprintf(stderr, "failed to create job: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_job_get_pushbuf(job, );
+if (err < 0) {
+fprintf(stderr, "failed to create push buffer: %s\n", strerror(-err));
+return 1;
+}
+
+err = vic_clear(vic, output, 1023, 1023, 0, 0);
+if (err < 0) {
+fprintf(stderr, "failed to clear surface: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_pushbuf_begin(pushbuf, 32, );
+if (err < 0) {
+fprintf(stderr, "failed to prepare push buffer: %s\n", strerror(-err));
+return err;
+}
+
+err = vic->ops->execute(vic, pushbuf, , output, NULL, 0);
+if (err < 0) {
+fprintf(stderr, "failed to execute operation: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_pushbuf_sync_cond(pushbuf, , vic->syncpt,
+  DRM_TEGRA_SYNC_COND_OP_DONE);
+if (err < 0) {
+fprintf(stderr, "failed to push syncpoint: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_pushbuf_end(pushbuf, ptr);
+if (err < 0) {
+fprintf(stderr, "failed to update push buffer: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_job_submit(job, NULL);
+if (err < 0) {
+fprintf(stderr, "failed to submit job: %s\n", strerror(-err));
+return err;
+}
+
+err = drm_tegra_job_wait(job, 10);
+if (err < 0) {
+fprintf(stderr, "failed to wait for job: %s\n", strerror(-err));
+return err;
+}
+
+drm_tegra_job_free(job);
+
+return 0;
+}
+
+/* fill bottom half of image to blue */
+static int fill(struct vic *vic, struct drm_tegra_channel *channel,
+struct vic_image *output)
+{
+struct drm_tegra_pushbuf *pushbuf;
+struct drm_tegra_job *job;
+uint32_t *ptr;
+int err;
+
+err = drm_tegra_job_new(channel, );
+if (err < 0) {
+fprintf(stderr, "failed to create job: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_job_get_pushbuf(job, );
+if (err < 0) {
+fprintf(stderr, "failed to create push buffer: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_pushbuf_begin(pushbuf, 32, );
+if (err < 0) {
+

[PATCH libdrm v2 23/25] tests: tegra: Add VIC clear test

2022-02-17 Thread Thierry Reding
From: Thierry Reding 

This test will attempt to use VIC to clear a surface.

Signed-off-by: Thierry Reding 
---
 tests/tegra/meson.build |   9 +++
 tests/tegra/vic-clear.c | 173 
 2 files changed, 182 insertions(+)
 create mode 100644 tests/tegra/vic-clear.c

diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
index 5380c71d870c..c7bf35899780 100644
--- a/tests/tegra/meson.build
+++ b/tests/tegra/meson.build
@@ -82,3 +82,12 @@ syncpt_timeout = executable(
   link_with : [libdrm, libdrm_tegra, libdrm_test, libdrm_test_tegra],
   install : with_install_tests,
 )
+
+vic_clear = executable(
+  'tegra-vic-clear',
+  files('vic-clear.c'),
+  include_directories : [inc_root, inc_drm, inc_tegra],
+  c_args : libdrm_c_args,
+  link_with : [libdrm, libdrm_tegra, libdrm_test, libdrm_test_tegra],
+  install : with_install_tests,
+)
diff --git a/tests/tegra/vic-clear.c b/tests/tegra/vic-clear.c
new file mode 100644
index ..da72782eda7a
--- /dev/null
+++ b/tests/tegra/vic-clear.c
@@ -0,0 +1,173 @@
+/*
+ * Copyright © 2018 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "util_math.h"
+
+#include "tegra.h"
+
+#include "host1x.h"
+#include "vic.h"
+
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
+
+int main(int argc, char *argv[])
+{
+const unsigned int format = VIC_PIXEL_FORMAT_A8R8G8B8;
+const unsigned int kind = VIC_BLK_KIND_PITCH;
+const unsigned int width = 16, height = 16;
+const char *device = "/dev/dri/renderD128";
+struct drm_tegra_channel *channel;
+struct drm_tegra_pushbuf *pushbuf;
+struct drm_tegra_job *job;
+struct vic_image *output;
+struct drm_tegra *drm;
+unsigned int version;
+struct vic *vic;
+uint32_t *pb;
+int fd, err;
+void *ptr;
+
+if (argc > 1)
+device = argv[1];
+
+fd = open(device, O_RDWR);
+if (fd < 0) {
+fprintf(stderr, "open() failed: %s\n", strerror(errno));
+return 1;
+}
+
+err = drm_tegra_new(fd, );
+if (err < 0) {
+fprintf(stderr, "failed to open Tegra device: %s\n", strerror(-err));
+close(fd);
+return 1;
+}
+
+err = drm_tegra_channel_open(drm, DRM_TEGRA_VIC, );
+if (err < 0) {
+fprintf(stderr, "failed to open channel to VIC: %s\n", strerror(-err));
+return 1;
+}
+
+version = drm_tegra_channel_get_version(channel);
+printf("version: %08x\n", version);
+
+err = vic_new(drm, channel, );
+if (err < 0) {
+fprintf(stderr, "failed to create VIC: %s\n", strerror(-err));
+return 1;
+}
+
+err = vic_image_new(vic, width, height, format, kind, 
DRM_TEGRA_CHANNEL_MAP_READ_WRITE,
+);
+if (err < 0) {
+fprintf(stderr, "failed to create output image: %d\n", err);
+return 1;
+}
+
+printf("image: %zu bytes\n", output->size);
+
+err = drm_tegra_bo_map(output->bo, );
+if (err < 0) {
+fprintf(stderr, "failed to map output image: %d\n", err);
+return 1;
+}
+
+memset(ptr, 0xff, output->size);
+drm_tegra_bo_unmap(output->bo);
+
+printf("output: %ux%u\n", output->width, output->height);
+vic_image_dump(output, stdout);
+
+err = drm_tegra_job_new(channel, );
+if (err < 0) {
+fprintf(stderr, "failed to create job: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_job_get_pushbuf(job, );
+if (err < 0) {
+fprintf(stderr, "failed to create push buffer: %s\n", strerror(-err));
+return 1;
+}
+
+err = drm_tegra_pushbuf_begin(pushbuf, 32, );
+if (err < 0) {
+fprintf(stderr, "failed to prepare push buffer: %s\n", strerror(-err));
+return 1;
+}
+
+err = vic_clear(vic, output, 1023, 0, 0, 1023);
+if (err < 0) {
+fprintf(stderr, "failed to 

[PATCH libdrm v2 22/25] tests: tegra: Add VIC 4.2 support

2022-02-17 Thread Thierry Reding
From: Thierry Reding 

The Video Image Composer (VIC) 4.2 can be found on NVIDIA Tegra194 SoCs.
It uses a different class (C5B6) that is slightly incompatible with the
class found on earlier generations, although it is backwards compatible
with the class implemented on Tegra186 (B1B6).

Signed-off-by: Thierry Reding 
---
 tests/tegra/meson.build |   2 +
 tests/tegra/vic.c   |   7 +
 tests/tegra/vic42.c | 374 +
 tests/tegra/vic42.h | 597 
 4 files changed, 980 insertions(+)
 create mode 100644 tests/tegra/vic42.c
 create mode 100644 tests/tegra/vic42.h

diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
index f50f3705c09f..5380c71d870c 100644
--- a/tests/tegra/meson.build
+++ b/tests/tegra/meson.build
@@ -40,6 +40,8 @@ libdrm_test_tegra = static_library(
 'vic40.h',
 'vic41.c',
 'vic41.h',
+'vic42.c',
+'vic42.h',
   ), config_file ],
   include_directories : [inc_root, inc_drm, inc_tegra],
   link_with : libdrm,
diff --git a/tests/tegra/vic.c b/tests/tegra/vic.c
index c5745ae58d29..4163e1846c32 100644
--- a/tests/tegra/vic.c
+++ b/tests/tegra/vic.c
@@ -142,6 +142,10 @@ int vic40_new(struct drm_tegra *drm, struct 
drm_tegra_channel *channel,
 int vic41_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
   struct vic **vicp);
 
+/* from vic42.c */
+int vic42_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
+  struct vic **vicp);
+
 int vic_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
 struct vic **vicp)
 {
@@ -158,6 +162,9 @@ int vic_new(struct drm_tegra *drm, struct drm_tegra_channel 
*channel,
 
 case 0x18:
 return vic41_new(drm, channel, vicp);
+
+case 0x19:
+return vic42_new(drm, channel, vicp);
 }
 
 return -ENOTSUP;
diff --git a/tests/tegra/vic42.c b/tests/tegra/vic42.c
new file mode 100644
index ..1f1935c3e249
--- /dev/null
+++ b/tests/tegra/vic42.c
@@ -0,0 +1,374 @@
+/*
+ * Copyright © 2018 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include "private.h"
+#include "tegra.h"
+#include "vic.h"
+#include "vic42.h"
+
+struct vic42 {
+struct vic base;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} config;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} filter;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} hist;
+};
+
+static int vic42_fill(struct vic *v, struct vic_image *output,
+  unsigned int left, unsigned int top,
+  unsigned int right, unsigned int bottom,
+  unsigned int alpha, unsigned int red,
+  unsigned int green, unsigned int blue)
+{
+struct vic42 *vic = container_of(v, struct vic42, base);
+ConfigStruct *c;
+int err;
+
+err = drm_tegra_bo_map(vic->config.bo, (void **));
+if (err < 0) {
+fprintf(stderr, "failed to map configuration structure: %s\n",
+strerror(-err));
+return err;
+}
+
+memset(c, 0, sizeof(*c));
+
+c->outputConfig.TargetRectTop = top;
+c->outputConfig.TargetRectLeft = left;
+c->outputConfig.TargetRectRight = right;
+c->outputConfig.TargetRectBottom = bottom;
+c->outputConfig.BackgroundAlpha = alpha;
+c->outputConfig.BackgroundR = red;
+c->outputConfig.BackgroundG = green;
+c->outputConfig.BackgroundB = blue;
+
+c->outputSurfaceConfig.OutPixelFormat = output->format;
+c->outputSurfaceConfig.OutBlkKind = output->kind;
+c->outputSurfaceConfig.OutBlkHeight = 0;
+c->outputSurfaceConfig.OutSurfaceWidth = output->width - 1;
+c->outputSurfaceConfig.OutSurfaceHeight = output->height - 1;
+c->outputSurfaceConfig.OutLumaWidth = 

[PATCH libdrm v2 21/25] tests: tegra: Add VIC 4.1 support

2022-02-17 Thread Thierry Reding
From: Thierry Reding 

The Video Image Composer (VIC) 4.1 can be found on NVIDIA Tegra186 SoCs.
It uses a different class (B1B6) that is slightly incompatible with the
class found on earlier generations.

Signed-off-by: Thierry Reding 
---
 tests/tegra/meson.build |   2 +
 tests/tegra/vic.c   |   7 +
 tests/tegra/vic41.c | 374 
 tests/tegra/vic41.h | 372 +++
 4 files changed, 755 insertions(+)
 create mode 100644 tests/tegra/vic41.c
 create mode 100644 tests/tegra/vic41.h

diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
index e9c2bc875a01..f50f3705c09f 100644
--- a/tests/tegra/meson.build
+++ b/tests/tegra/meson.build
@@ -38,6 +38,8 @@ libdrm_test_tegra = static_library(
 'vic30.h',
 'vic40.c',
 'vic40.h',
+'vic41.c',
+'vic41.h',
   ), config_file ],
   include_directories : [inc_root, inc_drm, inc_tegra],
   link_with : libdrm,
diff --git a/tests/tegra/vic.c b/tests/tegra/vic.c
index e0a97c059eca..c5745ae58d29 100644
--- a/tests/tegra/vic.c
+++ b/tests/tegra/vic.c
@@ -138,6 +138,10 @@ int vic30_new(struct drm_tegra *drm, struct 
drm_tegra_channel *channel,
 int vic40_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
   struct vic **vicp);
 
+/* from vic41.c */
+int vic41_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
+  struct vic **vicp);
+
 int vic_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
 struct vic **vicp)
 {
@@ -151,6 +155,9 @@ int vic_new(struct drm_tegra *drm, struct drm_tegra_channel 
*channel,
 
 case 0x21:
 return vic40_new(drm, channel, vicp);
+
+case 0x18:
+return vic41_new(drm, channel, vicp);
 }
 
 return -ENOTSUP;
diff --git a/tests/tegra/vic41.c b/tests/tegra/vic41.c
new file mode 100644
index ..0412fb24c537
--- /dev/null
+++ b/tests/tegra/vic41.c
@@ -0,0 +1,374 @@
+/*
+ * Copyright © 2018 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include "private.h"
+#include "tegra.h"
+#include "vic.h"
+#include "vic41.h"
+
+struct vic41 {
+struct vic base;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} config;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} filter;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} hist;
+};
+
+static int vic41_fill(struct vic *v, struct vic_image *output,
+  unsigned int left, unsigned int top,
+  unsigned int right, unsigned int bottom,
+  unsigned int alpha, unsigned int red,
+  unsigned int green, unsigned int blue)
+{
+struct vic41 *vic = container_of(v, struct vic41, base);
+ConfigStruct *c;
+int err;
+
+err = drm_tegra_bo_map(vic->config.bo, (void **));
+if (err < 0) {
+fprintf(stderr, "failed to map configuration structure: %s\n",
+strerror(-err));
+return err;
+}
+
+memset(c, 0, sizeof(*c));
+
+c->outputConfig.TargetRectTop = top;
+c->outputConfig.TargetRectLeft = left;
+c->outputConfig.TargetRectRight = right;
+c->outputConfig.TargetRectBottom = bottom;
+c->outputConfig.BackgroundAlpha = alpha;
+c->outputConfig.BackgroundR = red;
+c->outputConfig.BackgroundG = green;
+c->outputConfig.BackgroundB = blue;
+
+c->outputSurfaceConfig.OutPixelFormat = output->format;
+c->outputSurfaceConfig.OutBlkKind = output->kind;
+c->outputSurfaceConfig.OutBlkHeight = 0;
+c->outputSurfaceConfig.OutSurfaceWidth = output->width - 1;
+c->outputSurfaceConfig.OutSurfaceHeight = output->height - 1;
+c->outputSurfaceConfig.OutLumaWidth = output->stride - 1;
+c->outputSurfaceConfig.OutLumaHeight = 

[PATCH libdrm v2 20/25] tests: tegra: Add VIC 4.0 support

2022-02-17 Thread Thierry Reding
From: Thierry Reding 

The Video Image Composer (VIC) 4.0 can be found on NVIDIA Tegra210 SoCs.
It uses a different class (B0B6) that is slightly incompatible with the
class found on earlier generations.

Signed-off-by: Thierry Reding 
---
 tests/tegra/meson.build |   2 +
 tests/tegra/vic.c   |   7 +
 tests/tegra/vic40.c | 370 
 tests/tegra/vic40.h | 285 +++
 4 files changed, 664 insertions(+)
 create mode 100644 tests/tegra/vic40.c
 create mode 100644 tests/tegra/vic40.h

diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
index 1ee29d0afe1b..e9c2bc875a01 100644
--- a/tests/tegra/meson.build
+++ b/tests/tegra/meson.build
@@ -36,6 +36,8 @@ libdrm_test_tegra = static_library(
 'vic.h',
 'vic30.c',
 'vic30.h',
+'vic40.c',
+'vic40.h',
   ), config_file ],
   include_directories : [inc_root, inc_drm, inc_tegra],
   link_with : libdrm,
diff --git a/tests/tegra/vic.c b/tests/tegra/vic.c
index f24961ac5c6d..e0a97c059eca 100644
--- a/tests/tegra/vic.c
+++ b/tests/tegra/vic.c
@@ -134,6 +134,10 @@ void vic_image_dump(struct vic_image *image, FILE *fp)
 int vic30_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
   struct vic **vicp);
 
+/* from vic40.c */
+int vic40_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
+  struct vic **vicp);
+
 int vic_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
 struct vic **vicp)
 {
@@ -144,6 +148,9 @@ int vic_new(struct drm_tegra *drm, struct drm_tegra_channel 
*channel,
 switch (version) {
 case 0x40:
 return vic30_new(drm, channel, vicp);
+
+case 0x21:
+return vic40_new(drm, channel, vicp);
 }
 
 return -ENOTSUP;
diff --git a/tests/tegra/vic40.c b/tests/tegra/vic40.c
new file mode 100644
index ..1a5d2af6b0b6
--- /dev/null
+++ b/tests/tegra/vic40.c
@@ -0,0 +1,370 @@
+/*
+ * Copyright © 2018 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include "private.h"
+#include "tegra.h"
+#include "vic.h"
+#include "vic40.h"
+
+struct vic40 {
+struct vic base;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} config;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} filter;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} hist;
+};
+
+static int vic40_fill(struct vic *v, struct vic_image *output,
+  unsigned int left, unsigned int top,
+  unsigned int right, unsigned int bottom,
+  unsigned int alpha, unsigned int red,
+  unsigned int green, unsigned int blue)
+{
+struct vic40 *vic = container_of(v, struct vic40, base);
+ConfigStruct *c;
+int err;
+
+err = drm_tegra_bo_map(vic->config.bo, (void **));
+if (err < 0) {
+fprintf(stderr, "failed to map configuration structure: %s\n",
+strerror(-err));
+return err;
+}
+
+memset(c, 0, sizeof(*c));
+
+c->outputConfig.TargetRectTop = top;
+c->outputConfig.TargetRectLeft = left;
+c->outputConfig.TargetRectRight = right;
+c->outputConfig.TargetRectBottom = bottom;
+c->outputConfig.BackgroundAlpha = alpha;
+c->outputConfig.BackgroundR = red;
+c->outputConfig.BackgroundG = green;
+c->outputConfig.BackgroundB = blue;
+
+c->outputSurfaceConfig.OutPixelFormat = output->format;
+c->outputSurfaceConfig.OutBlkKind = output->kind;
+c->outputSurfaceConfig.OutBlkHeight = 0;
+c->outputSurfaceConfig.OutSurfaceWidth = output->width - 1;
+c->outputSurfaceConfig.OutSurfaceHeight = output->height - 1;
+c->outputSurfaceConfig.OutLumaWidth = output->stride - 1;
+c->outputSurfaceConfig.OutLumaHeight = output->height - 1;

[PATCH libdrm v2 19/25] tests: tegra: Add VIC 3.0 support

2022-02-17 Thread Thierry Reding
From: Thierry Reding 

The Video Image Composer (VIC) 3.0 can be found on NVIDIA Tegra124 SoCs.

Signed-off-by: Thierry Reding 
---
 tegra/private.h |   6 +
 tests/tegra/meson.build |   2 +
 tests/tegra/vic.c   |   8 +-
 tests/tegra/vic30.c | 458 
 tests/tegra/vic30.h | 439 ++
 5 files changed, 911 insertions(+), 2 deletions(-)
 create mode 100644 tests/tegra/vic30.c
 create mode 100644 tests/tegra/vic30.h

diff --git a/tegra/private.h b/tegra/private.h
index f134f3ea2cea..fc204e82e5e5 100644
--- a/tegra/private.h
+++ b/tegra/private.h
@@ -26,6 +26,7 @@
 #define __DRM_TEGRA_PRIVATE_H__ 1
 
 #include 
+#include 
 #include 
 
 #include 
@@ -34,6 +35,11 @@
 #include "tegra_drm.h"
 #include "tegra.h"
 
+#define container_of(ptr, type, member) ({  \
+const __typeof__(((type *)0)->member) *__mptr = (ptr);  \
+(type *)((char *)__mptr - offsetof(type, member));  \
+})
+
 enum host1x_class {
 HOST1X_CLASS_HOST1X = 0x01,
 HOST1X_CLASS_GR2D = 0x51,
diff --git a/tests/tegra/meson.build b/tests/tegra/meson.build
index 1f4721d059e1..1ee29d0afe1b 100644
--- a/tests/tegra/meson.build
+++ b/tests/tegra/meson.build
@@ -34,6 +34,8 @@ libdrm_test_tegra = static_library(
 'drm-test-tegra.h',
 'vic.c',
 'vic.h',
+'vic30.c',
+'vic30.h',
   ), config_file ],
   include_directories : [inc_root, inc_drm, inc_tegra],
   link_with : libdrm,
diff --git a/tests/tegra/vic.c b/tests/tegra/vic.c
index 43630db883bb..f24961ac5c6d 100644
--- a/tests/tegra/vic.c
+++ b/tests/tegra/vic.c
@@ -130,6 +130,10 @@ void vic_image_dump(struct vic_image *image, FILE *fp)
 drm_tegra_bo_unmap(image->bo);
 }
 
+/* from vic30.c */
+int vic30_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
+  struct vic **vicp);
+
 int vic_new(struct drm_tegra *drm, struct drm_tegra_channel *channel,
 struct vic **vicp)
 {
@@ -138,8 +142,8 @@ int vic_new(struct drm_tegra *drm, struct drm_tegra_channel 
*channel,
 version = drm_tegra_channel_get_version(channel);
 
 switch (version) {
-default:
-break;
+case 0x40:
+return vic30_new(drm, channel, vicp);
 }
 
 return -ENOTSUP;
diff --git a/tests/tegra/vic30.c b/tests/tegra/vic30.c
new file mode 100644
index ..1bea6e7036f3
--- /dev/null
+++ b/tests/tegra/vic30.c
@@ -0,0 +1,458 @@
+/*
+ * Copyright © 2018 NVIDIA Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+
+#include "private.h"
+#include "tegra.h"
+#include "vic.h"
+#include "vic30.h"
+
+struct vic30 {
+struct vic base;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} config;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} filter;
+
+struct {
+struct drm_tegra_mapping *map;
+struct drm_tegra_bo *bo;
+} hist;
+};
+
+static int vic30_fill(struct vic *v, struct vic_image *output,
+  unsigned int left, unsigned int top,
+  unsigned int right, unsigned int bottom,
+  unsigned int alpha, unsigned int red,
+  unsigned int green, unsigned int blue)
+{
+struct vic30 *vic = container_of(v, struct vic30, base);
+ConfigStruct *c;
+int err;
+
+err = drm_tegra_bo_map(vic->config.bo, (void **));
+if (err < 0) {
+fprintf(stderr, "failed to map configuration structure: %s\n",
+strerror(-err));
+return err;
+}
+
+memset(c, 0, sizeof(*c));
+
+c->surfaceList0Struct.TargetRectLeft = left;
+c->surfaceList0Struct.TargetRectTop = top;
+c->surfaceList0Struct.TargetRectRight = right;
+c->surfaceList0Struct.TargetRectBottom = bottom;
+
+c->blending0Struct.PixelFormat = output->format;
+

  1   2   3   4   >