date:20220617


Am 16.06.22 um 22:35 schrieb Alex Deucher:

Fixes:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9143:27: warning: 
variable 'abo' set but not used [-Wunused-but-set-variable]

Fixes: 047de3f17a83 ("drm/amdgpu: switch DM to atomic fence helpers v2")
Signed-off-by: Alex Deucher 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 33cd7a3d4ecb..33d575bcf964 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -9140,7 +9140,6 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
to_dm_crtc_state(drm_atomic_get_old_crtc_state(state, 
pcrtc));
int planes_count = 0, vpos, hpos;
unsigned long flags;
-   struct amdgpu_bo *abo;
uint32_t target_vblank, last_flip_vblank;
bool vrr_active = amdgpu_dm_vrr_active(acrtc_state);
bool pflip_present = false;
@@ -9212,7 +9211,6 @@ static void amdgpu_dm_commit_planes(struct 
drm_atomic_state *state,
continue;
}
  
-		abo = gem_to_amdgpu_bo(fb->obj[0]);

fill_dc_plane_info_and_addr(
dm->adev, new_plane_state,
afb->tiling_flags,

[RFT][PATCH v1 5/6] vfio/ccw: Add kmap_local_page() for memcpy

The pinned PFN list returned from vfio_pin_pages() is simply converted
using page_to_pfn() without protection, so direct access via memcpy()
will crash on S390 if the PFN is an IO PFN. Instead, the pages should
be touched using kmap_local_page().

Add kmap_local_page() before doing memcpy on "from".

Suggested-by: Jason Gunthorpe 
Signed-off-by: Nicolin Chen 
---
 drivers/s390/cio/vfio_ccw_cp.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
index e2b01115b3ec..12cbe66721af 100644
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ b/drivers/s390/cio/vfio_ccw_cp.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -235,7 +236,6 @@ static long copy_from_iova(struct vfio_device *vdev, void 
*to, u64 iova,
   unsigned long n)
 {
struct pfn_array pa = {0};
-   u64 from;
int i, ret;
unsigned long l, m;
 
@@ -251,7 +251,9 @@ static long copy_from_iova(struct vfio_device *vdev, void 
*to, u64 iova,
 
l = n;
for (i = 0; i < pa.pa_nr; i++) {
-   from = pa.pa_pfn[i] << PAGE_SHIFT;
+   struct page *page = pfn_to_page(pa.pa_pfn[i]);
+   void *from = kmap_local_page(page);
+
m = PAGE_SIZE;
if (i == 0) {
from += iova & (PAGE_SIZE - 1);
@@ -259,7 +261,8 @@ static long copy_from_iova(struct vfio_device *vdev, void 
*to, u64 iova,
}
 
m = min(l, m);
-   memcpy(to + (n - l), (void *)from, m);
+   memcpy(to + (n - l), from, m);
+   kunmap_local(from);
 
l -= m;
if (l == 0)
-- 
2.17.1

[RFT][PATCH v1 0/6] Update vfio_pin/unpin_pages API

This is a preparatory series for IOMMUFD v2 patches. It prepares for
replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
with IOMMUFD version.

There's a gap between these two versions: the vfio_iommu_type1 version
inputs a non-contiguous PFN list and outputs another PFN list for the
pinned physical page list, while the IOMMUFD version only supports a
contiguous address input by accepting the starting IO virtual address
of a set of pages to pin and by outputting to a physical page list.

The nature of existing callers mostly aligns with the IOMMUFD version,
except s390's vfio_ccw_cp code where some additional change is needed
along with this series. Overall, updating to "iova" and "phys_page"
does improve the caller side to some extent.

Also fix a misuse of physical address and virtual address in the s390's
crypto code. And update the input naming at the adjacent vfio_dma_rw().

This is on github:
https://github.com/nicolinc/iommufd/commits/vfio_pin_pages

Request for testing: I only did build for s390 and i915 code, so it'd
be nice to have people who have environment to run sanity accordingly.

Thanks!

Nicolin Chen (6):
  vfio/ap: Pass in physical address of ind to ap_aqic()
  vfio/ccw: Only pass in contiguous pages
  vfio: Pass in starting IOVA to vfio_pin/unpin_pages API
  vfio: Rename user_iova of vfio_dma_rw()
  vfio/ccw: Add kmap_local_page() for memcpy
  vfio: Replace phys_pfn with phys_page for vfio_pin_pages()

 .../driver-api/vfio-mediated-device.rst   |  6 +-
 arch/s390/include/asm/ap.h|  6 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 44 -
 drivers/s390/cio/vfio_ccw_cp.c| 90 ++-
 drivers/s390/crypto/ap_queue.c|  2 +-
 drivers/s390/crypto/vfio_ap_ops.c | 21 ++---
 drivers/vfio/vfio.c   | 38 
 drivers/vfio/vfio.h   |  6 +-
 drivers/vfio/vfio_iommu_type1.c   | 34 +++
 include/linux/vfio.h  |  8 +-
 10 files changed, 142 insertions(+), 113 deletions(-)

-- 
2.17.1

[RFT][PATCH v1 1/6] vfio/ap: Pass in physical address of ind to ap_aqic()

The ap_aqic() is called by vfio_ap_irq_enable() where it passes in a
virt value that's casted from a physical address "h_nib". Inside the
ap_aqic(), it does virt_to_phys() again.

Since ap_aqic() needs a physical address, let's just pass in a pa of
ind directly. So change the "ind" to "pa_ind".

Signed-off-by: Nicolin Chen 
---
 arch/s390/include/asm/ap.h| 6 +++---
 drivers/s390/crypto/ap_queue.c| 2 +-
 drivers/s390/crypto/vfio_ap_ops.c | 7 ---
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/s390/include/asm/ap.h b/arch/s390/include/asm/ap.h
index b515cfa62bd9..f508f5025e38 100644
--- a/arch/s390/include/asm/ap.h
+++ b/arch/s390/include/asm/ap.h
@@ -227,13 +227,13 @@ struct ap_qirq_ctrl {
  * ap_aqic(): Control interruption for a specific AP.
  * @qid: The AP queue number
  * @qirqctrl: struct ap_qirq_ctrl (64 bit value)
- * @ind: The notification indicator byte
+ * @pa_ind: Physical address of the notification indicator byte
  *
  * Returns AP queue status.
  */
 static inline struct ap_queue_status ap_aqic(ap_qid_t qid,
 struct ap_qirq_ctrl qirqctrl,
-void *ind)
+phys_addr_t pa_ind)
 {
unsigned long reg0 = qid | (3UL << 24);  /* fc 3UL is AQIC */
union {
@@ -241,7 +241,7 @@ static inline struct ap_queue_status ap_aqic(ap_qid_t qid,
struct ap_qirq_ctrl qirqctrl;
struct ap_queue_status status;
} reg1;
-   unsigned long reg2 = virt_to_phys(ind);
+   unsigned long reg2 = pa_ind;
 
reg1.qirqctrl = qirqctrl;
 
diff --git a/drivers/s390/crypto/ap_queue.c b/drivers/s390/crypto/ap_queue.c
index c48b0db824e3..a32457b4cbb8 100644
--- a/drivers/s390/crypto/ap_queue.c
+++ b/drivers/s390/crypto/ap_queue.c
@@ -34,7 +34,7 @@ static int ap_queue_enable_irq(struct ap_queue *aq, void *ind)
 
qirqctrl.ir = 1;
qirqctrl.isc = AP_ISC;
-   status = ap_aqic(aq->qid, qirqctrl, ind);
+   status = ap_aqic(aq->qid, qirqctrl, virt_to_phys(ind));
switch (status.response_code) {
case AP_RESPONSE_NORMAL:
case AP_RESPONSE_OTHERWISE_CHANGED:
diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
b/drivers/s390/crypto/vfio_ap_ops.c
index a7d2a95796d3..bb869b28cebd 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -154,7 +154,7 @@ static struct ap_queue_status vfio_ap_irq_disable(struct 
vfio_ap_queue *q)
int retries = 5;
 
do {
-   status = ap_aqic(q->apqn, aqic_gisa, NULL);
+   status = ap_aqic(q->apqn, aqic_gisa, 0);
switch (status.response_code) {
case AP_RESPONSE_OTHERWISE_CHANGED:
case AP_RESPONSE_NORMAL:
@@ -245,7 +245,8 @@ static struct ap_queue_status vfio_ap_irq_enable(struct 
vfio_ap_queue *q,
struct kvm_s390_gisa *gisa;
int nisc;
struct kvm *kvm;
-   unsigned long h_nib, g_pfn, h_pfn;
+   unsigned long g_pfn, h_pfn;
+   phys_addr_t h_nib;
int ret;
 
/* Verify that the notification indicator byte address is valid */
@@ -290,7 +291,7 @@ static struct ap_queue_status vfio_ap_irq_enable(struct 
vfio_ap_queue *q,
aqic_gisa.ir = 1;
aqic_gisa.gisa = (uint64_t)gisa >> 4;
 
-   status = ap_aqic(q->apqn, aqic_gisa, (void *)h_nib);
+   status = ap_aqic(q->apqn, aqic_gisa, h_nib);
switch (status.response_code) {
case AP_RESPONSE_NORMAL:
/* See if we did clear older IRQ configuration */
-- 
2.17.1

[RFT][PATCH v1 2/6] vfio/ccw: Only pass in contiguous pages

This driver is the only caller of vfio_pin/unpin_pages that might pass
in a non-contiguous PFN list, but in many cases it has a contiguous PFN
list to process. So letting VFIO API handle a non-contiguous PFN list
is actually counterproductive.

Add a pair of simple loops to pass in contiguous PFNs only, to have an
efficient implementation in VFIO.

Signed-off-by: Nicolin Chen 
---
 drivers/s390/cio/vfio_ccw_cp.c | 68 +++---
 1 file changed, 54 insertions(+), 14 deletions(-)

diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
index 0c2be9421ab7..4659c2e35877 100644
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ b/drivers/s390/cio/vfio_ccw_cp.c
@@ -90,6 +90,37 @@ static int pfn_array_alloc(struct pfn_array *pa, u64 iova, 
unsigned int len)
return 0;
 }
 
+/*
+ * pfn_array_unpin() - Unpin user pages in memory
+ * @pa: pfn_array on which to perform the operation
+ * @vdev: the vfio device to perform the operation
+ * @pa_nr: number of user pages to unpin
+ *
+ * Only unpin if any pages were pinned to begin with, i.e. pa_nr > 0,
+ * otherwise only clear pa->pa_nr
+ */
+static void pfn_array_unpin(struct pfn_array *pa,
+   struct vfio_device *vdev, int pa_nr)
+{
+   int unpinned = 0, npage = 1;
+
+   while (unpinned < pa_nr) {
+   unsigned long *first = &pa->pa_iova_pfn[unpinned];
+   unsigned long *last = &first[npage];
+
+   if (unpinned + npage < pa_nr && *first + npage == *last) {
+   npage++;
+   continue;
+   }
+
+   vfio_unpin_pages(vdev, first, npage);
+   unpinned += npage;
+   npage = 1;
+   }
+
+   pa->pa_nr = 0;
+}
+
 /*
  * pfn_array_pin() - Pin user pages in memory
  * @pa: pfn_array on which to perform the operation
@@ -101,34 +132,43 @@ static int pfn_array_alloc(struct pfn_array *pa, u64 
iova, unsigned int len)
  */
 static int pfn_array_pin(struct pfn_array *pa, struct vfio_device *vdev)
 {
+   int pinned = 0, npage = 1;
int ret = 0;
 
-   ret = vfio_pin_pages(vdev, pa->pa_iova_pfn, pa->pa_nr,
-IOMMU_READ | IOMMU_WRITE, pa->pa_pfn);
+   while (pinned < pa->pa_nr) {
+   unsigned long *first = &pa->pa_iova_pfn[pinned];
+   unsigned long *last = &first[npage];
 
-   if (ret < 0) {
-   goto err_out;
-   } else if (ret > 0 && ret != pa->pa_nr) {
-   vfio_unpin_pages(vdev, pa->pa_iova_pfn, ret);
-   ret = -EINVAL;
-   goto err_out;
+   if (pinned + npage < pa->pa_nr && *first + npage == *last) {
+   npage++;
+   continue;
+   }
+
+   ret = vfio_pin_pages(vdev, first, npage,
+IOMMU_READ | IOMMU_WRITE,
+&pa->pa_pfn[pinned]);
+   if (ret < 0) {
+   goto err_out;
+   } else if (ret > 0 && ret != npage) {
+   pinned += ret;
+   ret = -EINVAL;
+   goto err_out;
+   }
+   pinned += npage;
+   npage = 1;
}
 
return ret;
 
 err_out:
-   pa->pa_nr = 0;
-
+   pfn_array_unpin(pa, vdev, pinned);
return ret;
 }
 
 /* Unpin the pages before releasing the memory. */
 static void pfn_array_unpin_free(struct pfn_array *pa, struct vfio_device 
*vdev)
 {
-   /* Only unpin if any pages were pinned to begin with */
-   if (pa->pa_nr)
-   vfio_unpin_pages(vdev, pa->pa_iova_pfn, pa->pa_nr);
-   pa->pa_nr = 0;
+   pfn_array_unpin(pa, vdev, pa->pa_nr);
kfree(pa->pa_iova_pfn);
 }
 
-- 
2.17.1

[RFT][PATCH v1 3/6] vfio: Pass in starting IOVA to vfio_pin/unpin_pages API

The vfio_pin/unpin_pages() so far accepted arrays of PFNs of user IOVA.
Among all three callers, there was only one caller possibly passing in
a non-contiguous PFN list, which is now ensured to have contiguous PFN
inputs too.

Pass in the starting address with "iova" alone to simplify things, so
callers no longer need to maintain a PFN list or to pin/unpin one page
at a time. This also allows VFIO to use more efficient implementations
of pin/unpin_pages.

For now, also update vfio_iommu_type1 to fit this new parameter too,
while keeping its input intact (being user_iova) since we don't want
to spend too much effort swapping its parameters and local variables
at that level.

Signed-off-by: Nicolin Chen 
---
 .../driver-api/vfio-mediated-device.rst   |  4 +--
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 25 +++---
 drivers/s390/cio/vfio_ccw_cp.c|  4 +--
 drivers/s390/crypto/vfio_ap_ops.c |  9 +++
 drivers/vfio/vfio.c   | 26 +--
 drivers/vfio/vfio.h   |  4 +--
 drivers/vfio/vfio_iommu_type1.c   | 17 ++--
 include/linux/vfio.h  |  4 +--
 8 files changed, 41 insertions(+), 52 deletions(-)

diff --git a/Documentation/driver-api/vfio-mediated-device.rst 
b/Documentation/driver-api/vfio-mediated-device.rst
index eded8719180f..d28f8bcbfbc6 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -262,10 +262,10 @@ Translation APIs for Mediated Devices
 The following APIs are provided for translating user pfn to host pfn in a VFIO
 driver::
 
-   int vfio_pin_pages(struct vfio_device *device, unsigned long *user_pfn,
+   int vfio_pin_pages(struct vfio_device *device, dma_addr_t iova,
  int npage, int prot, unsigned long *phys_pfn);
 
-   int vfio_unpin_pages(struct vfio_device *device, unsigned long 
*user_pfn,
+   int vfio_unpin_pages(struct vfio_device *device, dma_addr_t iova,
int npage);
 
 These functions call back into the back-end IOMMU module by using the pin_pages
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index e2f6c56ab342..c9bdc3901f1e 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -231,19 +231,12 @@ static void intel_gvt_cleanup_vgpu_type_groups(struct 
intel_gvt *gvt)
 static void gvt_unpin_guest_page(struct intel_vgpu *vgpu, unsigned long gfn,
unsigned long size)
 {
+   unsigned long npage = roundup(size, PAGE_SIZE) / PAGE_SIZE;
struct drm_i915_private *i915 = vgpu->gvt->gt->i915;
-   int total_pages;
-   int npage;
int ret;
 
-   total_pages = roundup(size, PAGE_SIZE) / PAGE_SIZE;
-
-   for (npage = 0; npage < total_pages; npage++) {
-   unsigned long cur_gfn = gfn + npage;
-
-   ret = vfio_unpin_pages(&vgpu->vfio_device, &cur_gfn, 1);
-   drm_WARN_ON(&i915->drm, ret != 1);
-   }
+   ret = vfio_unpin_pages(&vgpu->vfio_device, gfn << PAGE_SHIFT, npage);
+   drm_WARN_ON(&i915->drm, ret != npage);
 }
 
 /* Pin a normal or compound guest page for dma. */
@@ -261,14 +254,14 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
 * on stack to hold pfns.
 */
for (npage = 0; npage < total_pages; npage++) {
-   unsigned long cur_gfn = gfn + npage;
+   unsigned long cur_iova = (gfn + npage) << PAGE_SHIFT;
unsigned long pfn;
 
-   ret = vfio_pin_pages(&vgpu->vfio_device, &cur_gfn, 1,
+   ret = vfio_pin_pages(&vgpu->vfio_device, cur_iova, 1,
 IOMMU_READ | IOMMU_WRITE, &pfn);
if (ret != 1) {
-   gvt_vgpu_err("vfio_pin_pages failed for gfn 0x%lx, ret 
%d\n",
-cur_gfn, ret);
+   gvt_vgpu_err("vfio_pin_pages failed for iova 0x%lx, ret 
%d\n",
+cur_iova, ret);
goto err;
}
 
@@ -312,7 +305,7 @@ static int gvt_dma_map_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
if (dma_mapping_error(dev, *dma_addr)) {
gvt_vgpu_err("DMA mapping failed for pfn 0x%lx, ret %d\n",
 page_to_pfn(page), ret);
-   gvt_unpin_guest_page(vgpu, gfn, size);
+   gvt_unpin_guest_page(vgpu, gfn << PAGE_SHIFT, size);
return -ENOMEM;
}
 
@@ -325,7 +318,7 @@ static void gvt_dma_unmap_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
struct device *dev = vgpu->gvt->gt->i915->drm.dev;
 
dma_unmap_page(dev, dma_addr, size, DMA_BIDIRECTIONAL);
-   gvt_unpin_guest_page(vgpu, gfn, size);
+   gvt_unpin_guest_page(vgpu, gfn << PAGE_SHIFT, size);
 }

[RFT][PATCH v1 4/6] vfio: Rename user_iova of vfio_dma_rw()

Following the updated vfio_pin/unpin_pages(), use the simpler "iova".

Signed-off-by: Nicolin Chen 
---
 drivers/vfio/vfio.c  | 6 +++---
 include/linux/vfio.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 861594dd461a..e8dbb0122e20 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -1996,13 +1996,13 @@ EXPORT_SYMBOL(vfio_unpin_pages);
  * not a real device DMA, it is not necessary to pin the user space memory.
  *
  * @device [in]: VFIO device
- * @user_iova [in] : base IOVA of a user space buffer
+ * @iova [in]  : base IOVA of a user space buffer
  * @data [in]  : pointer to kernel buffer
  * @len [in]   : kernel buffer length
  * @write  : indicate read or write
  * Return error code on failure or 0 on success.
  */
-int vfio_dma_rw(struct vfio_device *device, dma_addr_t user_iova, void *data,
+int vfio_dma_rw(struct vfio_device *device, dma_addr_t iova, void *data,
size_t len, bool write)
 {
struct vfio_container *container;
@@ -2018,7 +2018,7 @@ int vfio_dma_rw(struct vfio_device *device, dma_addr_t 
user_iova, void *data,
 
if (likely(driver && driver->ops->dma_rw))
ret = driver->ops->dma_rw(container->iommu_data,
- user_iova, data, len, write);
+ iova, data, len, write);
else
ret = -ENOTTY;
return ret;
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index edbad5d3d50a..99c3bf52c4da 100644
--- a/include/linux/vfio.h
+++ b/include/linux/vfio.h
@@ -151,7 +151,7 @@ extern int vfio_pin_pages(struct vfio_device *device, 
dma_addr_t iova,
  int npage, int prot, unsigned long *phys_pfn);
 extern int vfio_unpin_pages(struct vfio_device *device, dma_addr_t iova,
int npage);
-extern int vfio_dma_rw(struct vfio_device *device, dma_addr_t user_iova,
+extern int vfio_dma_rw(struct vfio_device *device, dma_addr_t iova,
   void *data, size_t len, bool write);
 
 /* each type has independent events */
-- 
2.17.1

Re: [PATCH 2/2] drm/bridge/tc358775: Fix DSI clock division for vsync delay calculation

2022-06-17 Thread Vinay Simha B N

Reviewed-by: Vinay Simha BN 

On Thu, Jun 16, 2022 at 3:55 AM Jiri Vanek  wrote:

> Use the same PCLK divide option (divide DSI clock to generate pixel clock)
> which is set to LVDS Configuration Register (LVCFG) also for a VSync delay
> calculation. Without this change an auxiliary variable could underflow
> during the calculation for some dual-link LVDS panels and then calculated
> VSync delay is wrong. This leads to a shifted picture on a panel.
>
> Tested-by: Jiri Vanek 
> Signed-off-by: Jiri Vanek 
> ---
>  drivers/gpu/drm/bridge/tc358775.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c
> b/drivers/gpu/drm/bridge/tc358775.c
> index cd2721ab02a9..fecb8558b49a 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -430,7 +430,7 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
> val = TC358775_VPCTRL_MSF(1);
>
> dsiclk = mode->crtc_clock * 3 * tc->bpc / tc->num_dsi_lanes / 1000;
> -   clkdiv = dsiclk / DIVIDE_BY_3 * tc->lvds_link;
> +   clkdiv = dsiclk / (tc->lvds_link == DUAL_LINK ? DIVIDE_BY_6 :
> DIVIDE_BY_3);
> byteclk = dsiclk / 4;
> t1 = hactive * (tc->bpc * 3 / 8) / tc->num_dsi_lanes;
> t2 = ((10 / clkdiv)) * (hactive + hback_porch + hsync_len +
> hfront_porch) / 1000;
> --
> 2.30.2
>
>

-- 
regards,
vinaysimha

Re: [PATCH 1/2] drm/bridge/tc358775: Return before displaying inappropriate error message

2022-06-17 Thread Vinay Simha B N

Reviewed-by: Vinay Simha BN 

On Thu, Jun 16, 2022 at 3:55 AM Jiri Vanek  wrote:

> Function for reading from i2c device register displays error message even
> if reading ends correctly. Add return to avoid falling through into
> the fail label.
>
> Signed-off-by: Jiri Vanek 
> ---
>  drivers/gpu/drm/bridge/tc358775.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/tc358775.c
> b/drivers/gpu/drm/bridge/tc358775.c
> index 62a7ef352daa..cd2721ab02a9 100644
> --- a/drivers/gpu/drm/bridge/tc358775.c
> +++ b/drivers/gpu/drm/bridge/tc358775.c
> @@ -339,6 +339,7 @@ static void d2l_read(struct i2c_client *i2c, u16 addr,
> u32 *val)
> goto fail;
>
> pr_debug("d2l: I2C : addr:%04x value:%08x\n", addr, *val);
> +   return;
>
>  fail:
> dev_err(&i2c->dev, "Error %d reading from subaddress 0x%x\n",
> --
> 2.30.2
>
>

-- 
regards,
vinaysimha

[RFT][PATCH v1 6/6] vfio: Replace phys_pfn with phys_page for vfio_pin_pages()

Most of the callers of vfio_pin_pages() want "struct page *" and the
low-level mm code to pin pages returns a list of "struct page *" too.
So there's no gain in converting "struct page *" to PFN in between.

Replace the output parameter phys_pfn list with a phys_page list, to
simplify callers. This also allows us to replace the vfio_iommu_type1
implementation with a more efficient one.

For now, also update vfio_iommu_type1 to fit this new parameter too.

Signed-off-by: Nicolin Chen 
---
 .../driver-api/vfio-mediated-device.rst   |  2 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c  | 19 ++-
 drivers/s390/cio/vfio_ccw_cp.c| 19 +--
 drivers/s390/crypto/vfio_ap_ops.c |  7 ---
 drivers/vfio/vfio.c   |  8 
 drivers/vfio/vfio.h   |  2 +-
 drivers/vfio/vfio_iommu_type1.c   | 19 +++
 include/linux/vfio.h  |  2 +-
 8 files changed, 37 insertions(+), 41 deletions(-)

diff --git a/Documentation/driver-api/vfio-mediated-device.rst 
b/Documentation/driver-api/vfio-mediated-device.rst
index d28f8bcbfbc6..070e51bb0bb6 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -263,7 +263,7 @@ The following APIs are provided for translating user pfn to 
host pfn in a VFIO
 driver::
 
int vfio_pin_pages(struct vfio_device *device, dma_addr_t iova,
- int npage, int prot, unsigned long *phys_pfn);
+ int npage, int prot, struct page **phys_page);
 
int vfio_unpin_pages(struct vfio_device *device, dma_addr_t iova,
int npage);
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index c9bdc3901f1e..669432999676 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -243,7 +243,7 @@ static void gvt_unpin_guest_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
 static int gvt_pin_guest_page(struct intel_vgpu *vgpu, unsigned long gfn,
unsigned long size, struct page **page)
 {
-   unsigned long base_pfn = 0;
+   struct page *base_page = NULL;
int total_pages;
int npage;
int ret;
@@ -255,26 +255,19 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
 */
for (npage = 0; npage < total_pages; npage++) {
unsigned long cur_iova = (gfn + npage) << PAGE_SHIFT;
-   unsigned long pfn;
+   struct page *cur_page;
 
ret = vfio_pin_pages(&vgpu->vfio_device, cur_iova, 1,
-IOMMU_READ | IOMMU_WRITE, &pfn);
+IOMMU_READ | IOMMU_WRITE, &cur_page);
if (ret != 1) {
gvt_vgpu_err("vfio_pin_pages failed for iova 0x%lx, ret 
%d\n",
 cur_iova, ret);
goto err;
}
 
-   if (!pfn_valid(pfn)) {
-   gvt_vgpu_err("pfn 0x%lx is not mem backed\n", pfn);
-   npage++;
-   ret = -EFAULT;
-   goto err;
-   }
-
if (npage == 0)
-   base_pfn = pfn;
-   else if (base_pfn + npage != pfn) {
+   base_page = cur_page;
+   else if (base_page + npage != cur_page) {
gvt_vgpu_err("The pages are not continuous\n");
ret = -EINVAL;
npage++;
@@ -282,7 +275,7 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
}
}
 
-   *page = pfn_to_page(base_pfn);
+   *page = base_page;
return 0;
 err:
gvt_unpin_guest_page(vgpu, gfn, npage * PAGE_SIZE);
diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
index 12cbe66721af..92be288dff74 100644
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ b/drivers/s390/cio/vfio_ccw_cp.c
@@ -24,8 +24,8 @@ struct pfn_array {
unsigned long   pa_iova;
/* Array that stores PFNs of the pages need to pin. */
unsigned long   *pa_iova_pfn;
-   /* Array that receives PFNs of the pages pinned. */
-   unsigned long   *pa_pfn;
+   /* Array that receives the pinned pages. */
+   struct page **pa_page;
/* Number of pages pinned from @pa_iova. */
int pa_nr;
 };
@@ -73,19 +73,19 @@ static int pfn_array_alloc(struct pfn_array *pa, u64 iova, 
unsigned int len)
 
pa->pa_iova_pfn = kcalloc(pa->pa_nr,
  sizeof(*pa->pa_iova_pfn) +
- sizeof(*pa->pa_pfn),
+ sizeof(*pa->pa_page),

[PULL] drm-misc-next

Hi Dave and Daniel,

here's the PR for drm-misc-next. AFAICT it contains mostly fixes and
cleanups. There's is one new driver for the LogiCVC display controller.

Best regards
Thomas

drm-misc-next-2022-06-17:
drm-misc-next for v5.20:

UAPI Changes:

Cross-subsystem Changes:

 * dma-buf: Add sync-file API; Set DMA mask for udmabuf devices

 * fbcon: Cleanups

 * fbdev: Disable firmware-device registration when first native driver loads

 * iosys-map: Documentation fixes

Core Changes:

 * edid: Use struct drm_edid in more places

 * gem-cma-helper: Improve documentation

 * of: Add data-lane helpers and convert drivers

 * syncobj: Fixes

Driver Changes:

 * amdgpu: Build fixes

 * ast: Support multiple outputs

 * bochs: Include 

 * bridge: adv7511: I2C fixes; anx7625: Fix error handling; lt6505: Kconfig 
fixes

 * display/dp: Documentation fixes

 * display/dp-mst: Read extended DPCD capabilities during system resume

 * logicvc: Add new driver

 * magag200: Build fixes

 * nouveau: Cleanups

 * panel: Add backlight support; nt36672a: DT backlight support

 * qxl: Cleanups

 * sun4i: HDMI PHY cleanups

 * vc4: Add support for BCM2711

 * virt-gpu: Avoid NULL dereference; Fix error checks; Cleanups

 * vkms: Allocate output buffer with vmalloc(); Fixes
The following changes since commit dfa687bffc8a4a21ed929c7dececf01b8f1f52ee:

  drm/bridge: lt9611uxc: Cancel only driver's work (2022-06-07 14:57:47 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-06-17

for you to fetch changes up to e4a8864f74e9e9e4a7eb93952a4cfa35c165c930:

  iosys-map: Fix typo in documentation (2022-06-16 16:44:34 -0700)


drm-misc-next for v5.20:

UAPI Changes:

Cross-subsystem Changes:

 * dma-buf: Add sync-file API; Set DMA mask for udmabuf devices

 * fbcon: Cleanups

 * fbdev: Disable firmware-device registration when first native driver loads

 * iosys-map: Documentation fixes

Core Changes:

 * edid: Use struct drm_edid in more places

 * gem-cma-helper: Improve documentation

 * of: Add data-lane helpers and convert drivers

 * syncobj: Fixes

Driver Changes:

 * amdgpu: Build fixes

 * ast: Support multiple outputs

 * bochs: Include 

 * bridge: adv7511: I2C fixes; anx7625: Fix error handling; lt6505: Kconfig 
fixes

 * display/dp: Documentation fixes

 * display/dp-mst: Read extended DPCD capabilities during system resume

 * logicvc: Add new driver

 * magag200: Build fixes

 * nouveau: Cleanups

 * panel: Add backlight support; nt36672a: DT backlight support

 * qxl: Cleanups

 * sun4i: HDMI PHY cleanups

 * vc4: Add support for BCM2711

 * virt-gpu: Avoid NULL dereference; Fix error checks; Cleanups

 * vkms: Allocate output buffer with vmalloc(); Fixes


Alex Deucher (1):
  drm/amdgpu/display: fix build when CONFIG_DEBUG_FS is not set

Antonio Borneo (1):
  drm: adv7511: override i2c address of cec before accessing it

Christophe Leroy (1):
  drm/nouveau/bios: Rename prom_init() and friends functions

Daniel Thompson (1):
  drm/cma-helper: Describe what a "contiguous chunk" actually means

Daniel Vetter (1):
  Revert "fbdev: Prevent probing generic drivers if a FB is already 
registered"

Douglas Anderson (1):
  drm: Fix htmldocs indentation warning w/ DP AUX power requirements

Geert Uytterhoeven (1):
  fbcon: Remove obsolete reference to initmem_freed

Igor Torrente (1):
  drm: vkms: Alloc the compose frame using vzalloc

Imre Deak (1):
  drm/dp/mst: Read the extended DPCD capabilities during system resume

Jani Nikula (6):
  drm/edid: fix CTA data block collection size for CTA version 3
  drm/edid: abstract cea data block collection size
  drm/edid: add block count and data helper functions for drm_edid
  drm/edid: keep track of alloc size in drm_do_get_edid()
  drm/edid: add new interfaces around struct drm_edid
  drm/probe-helper: abstract .get_modes() connector helper call

Jason Ekstrand (2):
  dma-buf: Add an API for exporting sync files (v14)
  dma-buf: Add an API for importing sync files (v10)

Javier Martinez Canillas (4):
  firmware: sysfb: Make sysfb_create_simplefb() return a pdev pointer
  firmware: sysfb: Add sysfb_disable() helper function
  fbdev: Disable sysfb device registration when removing conflicting FBs
  Revert "fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled"

Joel Selvaraj (2):
  drm/panel: nt36672a: add backlight support
  dt-bindings: display: novatek, nt36672a: add backlight property

Lucas De Marchi (1):
  iosys-map: Fix typo in documentation

Marek Vasut (16):
  drm: of: Add drm_of_get_data_lanes_count and drm_of_get_data_lanes_ep
  drm/bridge: anx7625: Convert to drm_of_get_data_lanes_count
  drm/bridge: icn6211: Convert to drm_of_get_data_lanes_count_ep
  drm/bridge: l

Re: [PATCH 03/96] drm/vc4: Migrate to new style legacy DAI naming flag

2022-06-17 Thread Maxime Ripard

On Thu, Jun 16, 2022 at 03:32:56PM +0100, Charles Keepax wrote:
> Change the legacy DAI naming flag from opting in to the new scheme
> (non_legacy_dai_naming), to opting out of it (legacy_dai_naming).
> This driver appears to be on the CPU side of the DAI link and
> currently uses the legacy naming, so add the new flag.
> 
> Signed-off-by: Charles Keepax 

Acked-by: Maxime Ripard 

Thanks!
Maxime

[PATCH v3 0/6] drm/meson: add support for MIPI DSI Display

The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver 
(ver 1.21a),
with a custom glue managing the IP resets, clock and data input similar to the 
DW-HDMI
glue on the same Amlogic SoCs.

This adds support for the glue managing the transceiver, mimicing the init flow 
provided
by Amlogic to setup the ENCL encoder, the glue, the transceiver, the digital 
D-PHY and the
Analog PHY in the proper way.

The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL 
encoder + VIU
pixel reader by the VCLK2 clock using the HDMI PLL.

The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the 
VCLK2 clock.

An optional "MEAS" clock can be enabled to measure the delay between each vsync 
feeding the
DW-MIPI-DSI transceiver.

This patchset is based on an earlier attempt at [1] for the AXG SoCs, but:
- the AXG has a single clock source for both transceiver + pixel, which makes 
it an
  exception instead of a rule, it's simpler to add support for G12A then add 
AXG on it
- previous glue code was a single monolitic code mixing encoders & bridges, 
this version
  is aligned on the previous cleanup done on HDMI & CVBS bridges architecture 
at [2]
- since the only output of AXG is DSI, AXG VPU support is post-poned until we 
implement
  single-clock DSI support specific case on top of this.

Changes from v2 at [4]:
- Fixed patch 3
- Added reviews from Jagan
- Rebased on v5.19-rc1

Changes from v1 at [3]:
- fixed DSI host bindings
- add reviewed-by tags for bindings
- moved magic values to defines thanks to Martin's searches
- added proper prefixes to defines
- moved phy_configure to phy_init() dw-mipi-dsi callback
- moved phy_on to a new phy_power_on() dw-mipi-dsi callback
- correctly return phy_init/configure errors to callback returns

[1] https://lore.kernel.org/r/20200907081825.1654-1-narmstr...@baylibre.com
[2] https://lore.kernel.org/r/20211020123947.2585572-1-narmstr...@baylibre.com
[3] https://lore.kernel.org/r/20200907081825.1654-1-narmstr...@baylibre.com
[4] https://lore.kernel.org/r/20220120083357.1541262-1-narmstr...@baylibre.com

Neil Armstrong (6):
  dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings
  dt-bindings: display: meson-vpu: add third DPI output port
  drm/meson: venc: add ENCL encoder setup for MIPI-DSI output
  drm/meson: vclk: add DSI clock config
  drm/meson: add DSI encoder
  drm/meson: add support for MIPI-DSI transceiver

 .../display/amlogic,meson-dw-mipi-dsi.yaml| 116 ++
 .../bindings/display/amlogic,meson-vpu.yaml   |   5 +
 drivers/gpu/drm/meson/Kconfig |   7 +
 drivers/gpu/drm/meson/Makefile|   3 +-
 drivers/gpu/drm/meson/meson_drv.c |   7 +
 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 358 ++
 drivers/gpu/drm/meson/meson_dw_mipi_dsi.h | 160 
 drivers/gpu/drm/meson/meson_encoder_dsi.c | 160 
 drivers/gpu/drm/meson/meson_encoder_dsi.h |  12 +
 drivers/gpu/drm/meson/meson_registers.h   |  25 ++
 drivers/gpu/drm/meson/meson_vclk.c|  47 +++
 drivers/gpu/drm/meson/meson_vclk.h|   1 +
 drivers/gpu/drm/meson/meson_venc.c| 211 ++-
 drivers/gpu/drm/meson/meson_venc.h|   6 +
 drivers/gpu/drm/meson/meson_vpp.h |   2 +
 15 files changed, 1117 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
 create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
 create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.h
 create mode 100644 drivers/gpu/drm/meson/meson_encoder_dsi.c
 create mode 100644 drivers/gpu/drm/meson/meson_encoder_dsi.h

-- 
2.25.1

[PATCH v3 1/6] dt-bindings: display: add Amlogic MIPI DSI Host Controller bindings

The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver 
(ver 1.21a),
with a custom glue managing the IP resets, clock and data input similar to the 
DW-HDMI Glue
on the same Amlogic SoCs.

Signed-off-by: Neil Armstrong 
Reviewed-by: Rob Herring 
---
 .../display/amlogic,meson-dw-mipi-dsi.yaml| 116 ++
 1 file changed, 116 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml 
b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
new file mode 100644
index ..e057659545a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-mipi-dsi.yaml
@@ -0,0 +1,116 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2020 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-mipi-dsi.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Amlogic specific extensions to the Synopsys Designware MIPI DSI Host 
Controller
+
+maintainers:
+  - Neil Armstrong 
+
+description: |
+  The Amlogic Meson Synopsys Designware Integration is composed of
+  - A Synopsys DesignWare MIPI DSI Host Controller IP
+  - A TOP control block controlling the Clocks & Resets of the IP
+
+allOf:
+  - $ref: dsi-controller.yaml#
+
+properties:
+  compatible:
+enum:
+  - amlogic,meson-g12a-dw-mipi-dsi
+
+  reg:
+maxItems: 1
+
+  clocks:
+minItems: 2
+
+  clock-names:
+minItems: 2
+items:
+  - const: pclk
+  - const: px_clk
+  - const: meas_clk
+
+  resets:
+minItems: 1
+
+  reset-names:
+items:
+  - const: top
+
+  phys:
+minItems: 1
+
+  phy-names:
+items:
+  - const: dphy
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input node to receive pixel data.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: DSI output node to panel.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+  - reset-names
+  - phys
+  - phy-names
+  - ports
+
+unevaluatedProperties: false
+
+examples:
+  - |
+dsi@7000 {
+  compatible = "amlogic,meson-g12a-dw-mipi-dsi";
+  reg = <0x6000 0x400>;
+  resets = <&reset_top>;
+  reset-names = "top";
+  clocks = <&clk_pclk>, <&clk_px>;
+  clock-names = "pclk", "px_clk";
+  phys = <&mipi_dphy>;
+  phy-names = "dphy";
+
+  ports {
+  #address-cells = <1>;
+  #size-cells = <0>;
+
+  /* VPU VENC Input */
+  mipi_dsi_venc_port: port@0 {
+  reg = <0>;
+
+  mipi_dsi_in: endpoint {
+   remote-endpoint = <&dpi_out>;
+  };
+  };
+
+  /* DSI Output */
+  mipi_dsi_panel_port: port@1 {
+  reg = <1>;
+
+  mipi_out_panel: endpoint {
+  remote-endpoint = <&mipi_in_panel>;
+  };
+  };
+  };
+};
-- 
2.25.1

[PATCH v3 2/6] dt-bindings: display: meson-vpu: add third DPI output port

Add third port corresponding to the ENCL DPI encoder used to connect
to DSI or LVDS transceivers.

Signed-off-by: Neil Armstrong 
Reviewed-by: Martin Blumenstingl 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/display/amlogic,meson-vpu.yaml   | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml 
b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
index 047fd69e0377..fdb42b14a099 100644
--- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
+++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
@@ -96,6 +96,11 @@ properties:
 description:
   A port node pointing to the HDMI-TX port node.
 
+  port@2:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+  A port node pointing to the DPI port node (e.g. DSI or LVDS transceiver).
+
   "#address-cells":
 const: 1
 
-- 
2.25.1

[PATCH v3 6/6] drm/meson: add support for MIPI-DSI transceiver

The Amlogic G12A/G12B/SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 
1.21a),
with a custom glue managing the IP resets, clock and data input similar to the 
DW-HDMI
Glue on other Amlogic SoCs.

This adds support for the Glue managing the transceiver, mimicing the init flow 
provided
by Amlogic to setup the ENCL encoder, the glue, the transceiver, the digital 
D-PHY and the
Analog PHY in the proper way.

An optional "MEAS" clock can be enabled to measure the delay between each vsync 
feeding the
DW-MIPI-DSI transceiver.

Signed-off-by: Neil Armstrong 
Reviewed-by: Jagan Teki 
---
 drivers/gpu/drm/meson/Kconfig |   7 +
 drivers/gpu/drm/meson/Makefile|   1 +
 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 358 ++
 drivers/gpu/drm/meson/meson_dw_mipi_dsi.h | 160 ++
 4 files changed, 526 insertions(+)
 create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
 create mode 100644 drivers/gpu/drm/meson/meson_dw_mipi_dsi.h

diff --git a/drivers/gpu/drm/meson/Kconfig b/drivers/gpu/drm/meson/Kconfig
index 6c70fc3214af..71a1364b51e1 100644
--- a/drivers/gpu/drm/meson/Kconfig
+++ b/drivers/gpu/drm/meson/Kconfig
@@ -17,3 +17,10 @@ config DRM_MESON_DW_HDMI
default y if DRM_MESON
select DRM_DW_HDMI
imply DRM_DW_HDMI_I2S_AUDIO
+
+config DRM_MESON_DW_MIPI_DSI
+   tristate "MIPI DSI Synopsys Controller support for Amlogic Meson 
Display"
+   depends on DRM_MESON
+   default y if DRM_MESON
+   select DRM_DW_MIPI_DSI
+   select GENERIC_PHY_MIPI_DPHY
diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 833e18c20603..43071bdbd4b9 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -6,3 +6,4 @@ meson-drm-y += meson_encoder_hdmi.o meson_encoder_dsi.o
 
 obj-$(CONFIG_DRM_MESON) += meson-drm.o
 obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
+obj-$(CONFIG_DRM_MESON_DW_MIPI_DSI) += meson_dw_mipi_dsi.o
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c 
b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
new file mode 100644
index ..52c8578914b6
--- /dev/null
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -0,0 +1,358 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2021 BayLibre, SAS
+ * Author: Neil Armstrong 
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "meson_drv.h"
+#include "meson_dw_mipi_dsi.h"
+#include "meson_registers.h"
+#include "meson_venc.h"
+
+#define DRIVER_NAME "meson-dw-mipi-dsi"
+#define DRIVER_DESC "Amlogic Meson MIPI-DSI DRM driver"
+
+struct meson_dw_mipi_dsi {
+   struct meson_drm *priv;
+   struct device *dev;
+   void __iomem *base;
+   struct phy *phy;
+   union phy_configure_opts phy_opts;
+   struct dw_mipi_dsi *dmd;
+   struct dw_mipi_dsi_plat_data pdata;
+   struct mipi_dsi_device *dsi_device;
+   const struct drm_display_mode *mode;
+   struct clk *px_clk;
+};
+
+#define encoder_to_meson_dw_mipi_dsi(x) \
+   container_of(x, struct meson_dw_mipi_dsi, encoder)
+
+static void meson_dw_mipi_dsi_hw_init(struct meson_dw_mipi_dsi *mipi_dsi)
+{
+   /* Software reset */
+   writel_bits_relaxed(MIPI_DSI_TOP_SW_RESET_DWC | 
MIPI_DSI_TOP_SW_RESET_INTR |
+   MIPI_DSI_TOP_SW_RESET_DPI | 
MIPI_DSI_TOP_SW_RESET_TIMING,
+   MIPI_DSI_TOP_SW_RESET_DWC | 
MIPI_DSI_TOP_SW_RESET_INTR |
+   MIPI_DSI_TOP_SW_RESET_DPI | 
MIPI_DSI_TOP_SW_RESET_TIMING,
+   mipi_dsi->base + MIPI_DSI_TOP_SW_RESET);
+   writel_bits_relaxed(MIPI_DSI_TOP_SW_RESET_DWC | 
MIPI_DSI_TOP_SW_RESET_INTR |
+   MIPI_DSI_TOP_SW_RESET_DPI | 
MIPI_DSI_TOP_SW_RESET_TIMING,
+   0, mipi_dsi->base + MIPI_DSI_TOP_SW_RESET);
+
+   /* Enable clocks */
+   writel_bits_relaxed(MIPI_DSI_TOP_CLK_SYSCLK_EN | 
MIPI_DSI_TOP_CLK_PIXCLK_EN,
+   MIPI_DSI_TOP_CLK_SYSCLK_EN | 
MIPI_DSI_TOP_CLK_PIXCLK_EN,
+   mipi_dsi->base + MIPI_DSI_TOP_CLK_CNTL);
+
+   /* Take memory out of power down */
+   writel_relaxed(0, mipi_dsi->base + MIPI_DSI_TOP_MEM_PD);
+}
+
+static int dw_mipi_dsi_phy_init(void *priv_data)
+{
+   struct meson_dw_mipi_dsi *mipi_dsi = priv_data;
+   unsigned int dpi_data_format, venc_data_width;
+   int ret;
+
+   ret = clk_set_rate(mipi_dsi->px_clk, 
mipi_dsi->phy_opts.mipi_dphy.hs_clk_rate);
+   if (ret) {
+   pr_err("Failed to set DSI PLL rate %lu\n",
+  mipi_dsi->phy_opts.mipi_dphy.hs_clk_rate);
+
+   return ret;
+   }
+
+   switch (mipi_dsi->dsi_device->format) {
+   case MIPI_DSI_FMT_RGB888:
+   dpi_data_forma

[PATCH v3 4/6] drm/meson: vclk: add DSI clock config

The DSI path used the ENCL pixel encoder, thus this adds a clock
config using the HDMI PLL in order to feed the ENCL encoder via the
VCLK2 path and the CTS_ENCL clock output.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_vclk.c | 47 ++
 drivers/gpu/drm/meson/meson_vclk.h |  1 +
 2 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_vclk.c 
b/drivers/gpu/drm/meson/meson_vclk.c
index 2a82119eb58e..5e4d982be1c8 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -55,6 +55,8 @@
 #define VCLK2_DIV_MASK 0xff
 #define VCLK2_DIV_EN   BIT(16)
 #define VCLK2_DIV_RESETBIT(17)
+#define CTS_ENCL_SEL_MASK  (0xf << 12)
+#define CTS_ENCL_SEL_SHIFT 12
 #define CTS_VDAC_SEL_MASK  (0xf << 28)
 #define CTS_VDAC_SEL_SHIFT 28
 #define HHI_VIID_CLK_CNTL  0x12c /* 0x4b offset in data sheet */
@@ -83,6 +85,7 @@
 #define VCLK_DIV12_EN  BIT(4)
 #define HHI_VID_CLK_CNTL2  0x194 /* 0x65 offset in data sheet */
 #define CTS_ENCI_ENBIT(0)
+#define CTS_ENCL_ENBIT(3)
 #define CTS_ENCP_ENBIT(2)
 #define CTS_VDAC_ENBIT(4)
 #define HDMI_TX_PIXEL_EN   BIT(5)
@@ -1024,6 +1027,47 @@ static void meson_vclk_set(struct meson_drm *priv, 
unsigned int pll_base_freq,
regmap_update_bits(priv->hhi, HHI_VID_CLK_CNTL, VCLK_EN, VCLK_EN);
 }
 
+static void meson_dsi_clock_config(struct meson_drm *priv, unsigned int freq)
+{
+   meson_hdmi_pll_generic_set(priv, freq * 10);
+
+   /* Setup vid_pll divider value /5 */
+   meson_vid_pll_set(priv, VID_PLL_DIV_5);
+
+   /* Disable VCLK2 */
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_EN, 0);
+
+   /* Setup the VCLK2 divider value /2 */
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_DIV, VCLK2_DIV_MASK, 2 - 1);
+
+   /* select vid_pll for vclk2 */
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL,
+  VCLK2_SEL_MASK, (0 << VCLK2_SEL_SHIFT));
+
+   /* enable vclk2 gate */
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_EN, VCLK2_EN);
+
+   /* select vclk2_div1 for encl */
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_DIV,
+  CTS_ENCL_SEL_MASK, (8 << CTS_ENCL_SEL_SHIFT));
+
+   /* release vclk2_div_reset and enable vclk2_div */
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_DIV, VCLK2_DIV_EN | 
VCLK2_DIV_RESET,
+  VCLK2_DIV_EN);
+
+   /* enable vclk2_div1 gate */
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_DIV1_EN, 
VCLK2_DIV1_EN);
+
+   /* reset vclk2 */
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_SOFT_RESET, 
VCLK2_SOFT_RESET);
+   regmap_update_bits(priv->hhi, HHI_VIID_CLK_CNTL, VCLK2_SOFT_RESET, 0);
+
+   /* enable encl_clk */
+   regmap_update_bits(priv->hhi, HHI_VID_CLK_CNTL2, CTS_ENCL_EN, 
CTS_ENCL_EN);
+
+   usleep_range(1, 11000);
+}
+
 void meson_vclk_setup(struct meson_drm *priv, unsigned int target,
  unsigned int phy_freq, unsigned int vclk_freq,
  unsigned int venc_freq, unsigned int dac_freq,
@@ -1050,6 +1094,9 @@ void meson_vclk_setup(struct meson_drm *priv, unsigned 
int target,
meson_vclk_set(priv, phy_freq, 0, 0, 0,
   VID_PLL_DIV_5, 2, 1, 1, false, false);
return;
+   } else if (target == MESON_VCLK_TARGET_DSI) {
+   meson_dsi_clock_config(priv, phy_freq);
+   return;
}
 
hdmi_tx_div = vclk_freq / dac_freq;
diff --git a/drivers/gpu/drm/meson/meson_vclk.h 
b/drivers/gpu/drm/meson/meson_vclk.h
index 60617aaf18dd..1152b3af8d2e 100644
--- a/drivers/gpu/drm/meson/meson_vclk.h
+++ b/drivers/gpu/drm/meson/meson_vclk.h
@@ -17,6 +17,7 @@ enum {
MESON_VCLK_TARGET_CVBS = 0,
MESON_VCLK_TARGET_HDMI = 1,
MESON_VCLK_TARGET_DMT = 2,
+   MESON_VCLK_TARGET_DSI = 3,
 };
 
 /* 27MHz is the CVBS Pixel Clock */
-- 
2.25.1

[PATCH v3 5/6] drm/meson: add DSI encoder

This adds an encoder bridge designed to drive a MIPI-DSI display
by using the ENCL encoder through the internal MIPI DSI transceiver
connected to the output of the ENCL pixel encoder.

Signed-off-by: Neil Armstrong 
Reviewed-by: Jagan Teki 
---
 drivers/gpu/drm/meson/Makefile|   2 +-
 drivers/gpu/drm/meson/meson_drv.c |   7 +
 drivers/gpu/drm/meson/meson_encoder_dsi.c | 160 ++
 drivers/gpu/drm/meson/meson_encoder_dsi.h |  12 ++
 4 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/meson/meson_encoder_dsi.c
 create mode 100644 drivers/gpu/drm/meson/meson_encoder_dsi.h

diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile
index 3afa31bdc950..833e18c20603 100644
--- a/drivers/gpu/drm/meson/Makefile
+++ b/drivers/gpu/drm/meson/Makefile
@@ -2,7 +2,7 @@
 meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_encoder_cvbs.o
 meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o 
meson_overlay.o
 meson-drm-y += meson_rdma.o meson_osd_afbcd.o
-meson-drm-y += meson_encoder_hdmi.o
+meson-drm-y += meson_encoder_hdmi.o meson_encoder_dsi.o
 
 obj-$(CONFIG_DRM_MESON) += meson-drm.o
 obj-$(CONFIG_DRM_MESON_DW_HDMI) += meson_dw_hdmi.o
diff --git a/drivers/gpu/drm/meson/meson_drv.c 
b/drivers/gpu/drm/meson/meson_drv.c
index 1b70938cfd2c..896994862ad7 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -34,6 +34,7 @@
 #include "meson_registers.h"
 #include "meson_encoder_cvbs.h"
 #include "meson_encoder_hdmi.h"
+#include "meson_encoder_dsi.h"
 #include "meson_viu.h"
 #include "meson_vpp.h"
 #include "meson_rdma.h"
@@ -324,6 +325,12 @@ static int meson_drv_bind_master(struct device *dev, bool 
has_components)
if (ret)
goto exit_afbcd;
 
+   if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
+   ret = meson_encoder_dsi_init(priv);
+   if (ret)
+   goto free_drm;
+   }
+
ret = meson_plane_create(priv);
if (ret)
goto exit_afbcd;
diff --git a/drivers/gpu/drm/meson/meson_encoder_dsi.c 
b/drivers/gpu/drm/meson/meson_encoder_dsi.c
new file mode 100644
index ..20485a254ac4
--- /dev/null
+++ b/drivers/gpu/drm/meson/meson_encoder_dsi.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2016 BayLibre, SAS
+ * Author: Neil Armstrong 
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "meson_drv.h"
+#include "meson_encoder_dsi.h"
+#include "meson_registers.h"
+#include "meson_venc.h"
+#include "meson_vclk.h"
+
+struct meson_encoder_dsi {
+   struct drm_encoder encoder;
+   struct drm_bridge bridge;
+   struct drm_bridge *next_bridge;
+   struct meson_drm *priv;
+};
+
+#define bridge_to_meson_encoder_dsi(x) \
+   container_of(x, struct meson_encoder_dsi, bridge)
+
+static int meson_encoder_dsi_attach(struct drm_bridge *bridge,
+   enum drm_bridge_attach_flags flags)
+{
+   struct meson_encoder_dsi *encoder_dsi = 
bridge_to_meson_encoder_dsi(bridge);
+
+   return drm_bridge_attach(bridge->encoder, encoder_dsi->next_bridge,
+&encoder_dsi->bridge, flags);
+}
+
+static void meson_encoder_dsi_mode_set(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode,
+  const struct drm_display_mode 
*adjusted_mode)
+{
+   struct meson_encoder_dsi *encoder_dsi = 
bridge_to_meson_encoder_dsi(bridge);
+   struct meson_drm *priv = encoder_dsi->priv;
+
+   meson_vclk_setup(priv, MESON_VCLK_TARGET_DSI, mode->clock, 0, 0, 0, 
false);
+
+   meson_venc_mipi_dsi_mode_set(priv, mode);
+   meson_encl_load_gamma(priv);
+
+   writel_relaxed(0, priv->io_base + _REG(ENCL_VIDEO_EN));
+
+   writel_bits_relaxed(ENCL_VIDEO_MODE_ADV_VFIFO_EN, 
ENCL_VIDEO_MODE_ADV_VFIFO_EN,
+   priv->io_base + _REG(ENCL_VIDEO_MODE_ADV));
+   writel_relaxed(0, priv->io_base + _REG(ENCL_TST_EN));
+}
+
+static void meson_encoder_dsi_atomic_enable(struct drm_bridge *bridge,
+   struct drm_bridge_state 
*bridge_state)
+{
+   struct meson_encoder_dsi *encoder_dsi = 
bridge_to_meson_encoder_dsi(bridge);
+   struct meson_drm *priv = encoder_dsi->priv;
+
+   writel_bits_relaxed(BIT(0), 0, priv->io_base + 
_REG(VPP_WRAP_OSD1_MATRIX_EN_CTRL));
+
+   writel_relaxed(1, priv->io_base + _REG(ENCL_VIDEO_EN));
+}
+
+static void meson_encoder_dsi_atomic_disable(struct drm_bridge *bridge,
+struct drm_bridge_state 
*bridge_state)
+{
+   struct meson_encoder_dsi *meson_encoder_dsi =
+   bridge_to_meson_enco

[PATCH v3 3/6] drm/meson: venc: add ENCL encoder setup for MIPI-DSI output

This adds supports for the ENCL encoder connected to a MIPI-DSI transceiver on 
the
Amlogic AXG, G12A, G12B & SM1 SoCs.

Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_registers.h |  25 +++
 drivers/gpu/drm/meson/meson_venc.c  | 211 +++-
 drivers/gpu/drm/meson/meson_venc.h  |   6 +
 drivers/gpu/drm/meson/meson_vpp.h   |   2 +
 4 files changed, 242 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_registers.h 
b/drivers/gpu/drm/meson/meson_registers.h
index 0f3cafab8860..3d73d00a1f4c 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -812,6 +812,7 @@
 #define VENC_STATA 0x1b6d
 #define VENC_INTCTRL 0x1b6e
 #defineVENC_INTCTRL_ENCI_LNRST_INT_EN  BIT(1)
+#defineVENC_INTCTRL_ENCP_LNRST_INT_EN  BIT(9)
 #define VENC_INTFLAG 0x1b6f
 #define VENC_VIDEO_TST_EN 0x1b70
 #define VENC_VIDEO_TST_MDSEL 0x1b71
@@ -1192,7 +1193,11 @@
 #define ENCL_VIDEO_PB_OFFST 0x1ca5
 #define ENCL_VIDEO_PR_OFFST 0x1ca6
 #define ENCL_VIDEO_MODE 0x1ca7
+#defineENCL_PX_LN_CNT_SHADOW_ENBIT(15)
 #define ENCL_VIDEO_MODE_ADV 0x1ca8
+#defineENCL_VIDEO_MODE_ADV_VFIFO_ENBIT(3)
+#defineENCL_VIDEO_MODE_ADV_GAIN_HDTV   BIT(4)
+#defineENCL_SEL_GAMMA_RGB_IN   BIT(10)
 #define ENCL_DBG_PX_RST 0x1ca9
 #define ENCL_DBG_LN_RST 0x1caa
 #define ENCL_DBG_PX_INT 0x1cab
@@ -1219,11 +1224,14 @@
 #define ENCL_VIDEO_VOFFST 0x1cc0
 #define ENCL_VIDEO_RGB_CTRL 0x1cc1
 #define ENCL_VIDEO_FILT_CTRL 0x1cc2
+#defineENCL_VIDEO_FILT_CTRL_BYPASS_FILTER  BIT(12)
 #define ENCL_VIDEO_OFLD_VPEQ_OFST 0x1cc3
 #define ENCL_VIDEO_OFLD_VOAV_OFST 0x1cc4
 #define ENCL_VIDEO_MATRIX_CB 0x1cc5
 #define ENCL_VIDEO_MATRIX_CR 0x1cc6
 #define ENCL_VIDEO_RGBIN_CTRL 0x1cc7
+#defineENCL_VIDEO_RGBIN_RGBBIT(0)
+#defineENCL_VIDEO_RGBIN_ZBLK   BIT(1)
 #define ENCL_MAX_LINE_SWITCH_POINT 0x1cc8
 #define ENCL_DACSEL_0 0x1cc9
 #define ENCL_DACSEL_1 0x1cca
@@ -1300,13 +1308,28 @@
 #define RDMA_STATUS2 0x1116
 #define RDMA_STATUS3 0x1117
 #define L_GAMMA_CNTL_PORT 0x1400
+#defineL_GAMMA_CNTL_PORT_VCOM_POL  BIT(7)  /* RW */
+#defineL_GAMMA_CNTL_PORT_RVS_OUT   BIT(6)  /* RW */
+#defineL_GAMMA_CNTL_PORT_ADR_RDY   BIT(5)  /* Read Only */
+#defineL_GAMMA_CNTL_PORT_WR_RDYBIT(4)  /* Read Only */
+#defineL_GAMMA_CNTL_PORT_RD_RDYBIT(3)  /* Read Only */
+#defineL_GAMMA_CNTL_PORT_TRBIT(2)  /* RW */
+#defineL_GAMMA_CNTL_PORT_SET   BIT(1)  /* RW */
+#defineL_GAMMA_CNTL_PORT_ENBIT(0)  /* RW */
 #define L_GAMMA_DATA_PORT 0x1401
 #define L_GAMMA_ADDR_PORT 0x1402
+#defineL_GAMMA_ADDR_PORT_RDBIT(12)
+#defineL_GAMMA_ADDR_PORT_AUTO_INC  BIT(11)
+#defineL_GAMMA_ADDR_PORT_SEL_R BIT(10)
+#defineL_GAMMA_ADDR_PORT_SEL_G BIT(9)
+#defineL_GAMMA_ADDR_PORT_SEL_B BIT(8)
+#defineL_GAMMA_ADDR_PORT_ADDR  GENMASK(7, 0)
 #define L_GAMMA_VCOM_HSWITCH_ADDR 0x1403
 #define L_RGB_BASE_ADDR 0x1405
 #define L_RGB_COEFF_ADDR 0x1406
 #define L_POL_CNTL_ADDR 0x1407
 #define L_DITH_CNTL_ADDR 0x1408
+#defineL_DITH_CNTL_DITH10_EN   BIT(10)
 #define L_GAMMA_PROBE_CTRL 0x1409
 #define L_GAMMA_PROBE_COLOR_L 0x140a
 #define L_GAMMA_PROBE_COLOR_H 0x140b
@@ -1363,6 +1386,8 @@
 #define L_LCD_PWM1_HI_ADDR 0x143f
 #define L_INV_CNT_ADDR 0x1440
 #define L_TCON_MISC_SEL_ADDR 0x1441
+#defineL_TCON_MISC_SEL_STV1BIT(4)
+#defineL_TCON_MISC_SEL_STV2BIT(5)
 #define L_DUAL_PORT_CNTL_ADDR 0x1442
 #define MLVDS_CLK_CTL1_HI 0x1443
 #define MLVDS_CLK_CTL1_LO 0x1444
diff --git a/drivers/gpu/drm/meson/meson_venc.c 
b/drivers/gpu/drm/meson/meson_venc.c
index 3c55ed003359..eb2ac0549d46 100644
--- a/drivers/gpu/drm/meson/meson_venc.c
+++ b/drivers/gpu/drm/meson/meson_venc.c
@@ -6,6 +6,7 @@
  */
 
 #include 
+#include 
 
 #include 
 
@@ -1557,6 +1558,205 @@ void meson_venc_hdmi_mode_set(struct meson_drm *priv, 
int vic,
 }
 EXPORT_SYMBOL_GPL(meson_venc_hdmi_mode_set);
 
+static unsigned short meson_encl_gamma_table[256] = {
+   0, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40, 44, 48, 52, 56, 60,
+   64, 68, 72, 76, 80, 84, 88, 92, 96, 100, 104, 108, 112, 116, 120, 124,
+   128, 132, 136, 140, 144, 148, 152, 156, 160, 164, 168, 172, 176, 180, 
184, 188,
+   192, 196, 200, 204, 208, 212, 216, 220, 224, 228, 232, 236, 240, 244, 
248, 252,
+   256, 260, 264, 268, 272, 276, 280, 284, 288, 292, 296, 300, 304, 308, 
312, 316,
+   320, 324, 328, 332, 336, 340, 344, 348, 352, 356, 360, 364, 368, 372, 
376, 380,
+   384, 388, 392, 396, 400, 404, 408, 412, 416, 420, 424, 428, 432, 436, 
440, 444,
+

Re: [PATCH v5 00/13] Add MEMORY_DEVICE_COHERENT for coherent device memory mapping

On 17.06.22 04:19, Andrew Morton wrote:
> On Tue, 31 May 2022 15:00:28 -0500 Alex Sierra  wrote:
> 
>> This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
>> for current 5.18.0
> 
> I plan to move this series into the non-rebasing mm-stable branch in a
> few days.  Unless sternly told not to do so!
> 

I want to double-check some things regarding PageAnonExclusive
interaction. I'm busy, but I'll try prioritizing it.

-- 
Thanks,

David / dhildenb

[PATCH 1/2] dt-bindings: display: simple: add Ampire AM-800600P5TMQW-TB8H panel

2022-06-17 Thread Bastian Krause

Add Ampire AM-800600P5TMQW-TB8H 8" TFT LCD panel compatible string.

Signed-off-by: Bastian Krause 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 21ba90c9fe338..00a2bffa0ce82 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -35,6 +35,8 @@ properties:
   - ampire,am-480272h3tmqw-t01h
 # Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel
   - ampire,am800480r3tmqwa1h
+# Ampire AM-800600P5TMQW-TB8H 8.0" SVGA TFT LCD panel
+  - ampire,am800600p5tmqw-tb8h
 # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
   - auo,b101aw03
 # AU Optronics Corporation 10.1" WSVGA TFT LCD panel
-- 
2.30.2

[PATCH 2/2] drm/panel: simple: add AM-800600P5TMQW-TB8H

2022-06-17 Thread Bastian Krause

Add support for the Ampire AM-800600P5TMQW-TB8H 800x600 panel. Data
sheet is currently not publicly available, unfortunately.

Signed-off-by: Bastian Krause 
---
 drivers/gpu/drm/panel/panel-simple.c | 33 
 1 file changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 4a2e580a2f7b7..3a61873dd887c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -778,6 +778,36 @@ static const struct panel_desc ampire_am800480r3tmqwa1h = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
 };
 
+static const struct display_timing ampire_am800600p5tmqw_tb8h_timing = {
+   .pixelclock = { 3450, 3960, 5040 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 12, 112, 312 },
+   .hback_porch = { 87, 87, 48 },
+   .hsync_len = { 1, 1, 40 },
+   .vactive = { 600, 600, 600 },
+   .vfront_porch = { 1, 21, 61 },
+   .vback_porch = { 38, 38, 19 },
+   .vsync_len = { 1, 1, 20 },
+   .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+   DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
+   DISPLAY_FLAGS_SYNC_POSEDGE,
+};
+
+static const struct panel_desc ampire_am800600p5tmqwtb8h = {
+   .timings = &ire_am800600p5tmqw_tb8h_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 162,
+   .height = 122,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH |
+   DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE |
+   DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE,
+   .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
 static const struct display_timing santek_st0700i5y_rbslw_f_timing = {
.pixelclock = { 2640, 3330, 4680 },
.hactive = { 800, 800, 800 },
@@ -3754,6 +3784,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = &ire_am800480r3tmqwa1h,
+   }, {
+   .compatible = "ampire,am800600p5tmqwtb8h",
+   .data = &ire_am800600p5tmqwtb8h,
}, {
.compatible = "arm,rtsm-display",
.data = &arm_rtsm,
-- 
2.30.2

[PATCH 1/2] iosys-map: Add per-word read

2022-06-17 Thread Lucas De Marchi

Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.

Employ a similar trick as __seqprop() by using _Generic() to generate
only the specific call based on a type-compatible variable.

For a pariticular i915 workload producing GPU context switches,
__get_engine_usage_record() is particularly hot since the engine usage
is read from device local memory with dgfx, possibly multiple times
since it's racy. Test execution time for this test shows a ~12.5%
improvement with DG2:

Before:
nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07;
median = 9.52548e+06; var = 526149;
After:
nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06;
median = 8.33955e+06; var = 333113;

Other things attempted that didn't prove very useful:
1) Change the _Generic() on x86 to just dereference the memory address
2) Change __get_engine_usage_record() to do just 1 read per loop,
   comparing with the previous value read
3) Change __get_engine_usage_record() to access the fields directly as it
   was before the conversion to iosys-map

(3) did gave a small improvement (~3%), but doesn't seem to scale well
to other similar cases in the driver.

Additional test by Chris Wilson using gem_create from igt with some
changes to track object creation time. This happens to accidentally
stress this code path:

Pre iosys_map conversion of engine busyness:
lmem0: Creating262144 4KiB objects took 59274.2ms

Unpatched:
lmem0: Creating262144 4KiB objects took 108830.2ms

With readl (this patch):
lmem0: Creating262144 4KiB objects took 61348.6ms

s/readl/READ_ONCE/
lmem0: Creating262144 4KiB objects took 61333.2ms

So we do take a little bit more time than before the conversion, but
that is due to other factors: bringing the READ_ONCE back would be as
good as just doing this conversion.

v2:
- Remove default from _Generic() - callers wanting to read more
  than u64 should use iosys_map_memcpy_from()
- Add READ_ONCE() cases dereferencing the pointer when using system
  memory

Signed-off-by: Lucas De Marchi 
Reviewed-by: Christian König  # v1
---
 include/linux/iosys-map.h | 45 +++
 1 file changed, 36 insertions(+), 9 deletions(-)

diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index 4b8406ee8bc4..f59dd00ed202 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -6,6 +6,7 @@
 #ifndef __IOSYS_MAP_H__
 #define __IOSYS_MAP_H__
 
+#include 
 #include 
 #include 
 
@@ -333,6 +334,26 @@ static inline void iosys_map_memset(struct iosys_map *dst, 
size_t offset,
memset(dst->vaddr + offset, value, len);
 }
 
+#ifdef CONFIG_64BIT
+#define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) 
\
+   u64: val_ = readq(vaddr_iomem_)
+#else
+#define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) 
\
+   u64: memcpy_fromio(&(val_), vaddr_iomem__, sizeof(u64))
+#endif
+
+#define __iosys_map_rd_io(val__, vaddr_iomem__, type__) _Generic(val__,
\
+   u8: val__ = readb(vaddr_iomem__),   
\
+   u16: val__ = readw(vaddr_iomem__),  
\
+   u32: val__ = readl(vaddr_iomem__),  
\
+   __iosys_map_rd_io_u64_case(val__, vaddr_iomem__))
+
+#define __iosys_map_rd_sys(val__, vaddr__, type__) ({  
\
+   compiletime_assert(sizeof(type__) <= sizeof(u64),   
\
+  "Unsupported access size for __iosys_map_rd_sys()"); 
\
+   val__ = READ_ONCE(*((type__ *)vaddr__));
\
+})
+
 /**
  * iosys_map_rd - Read a C-type value from the iosys_map
  *
@@ -340,16 +361,21 @@ static inline void iosys_map_memset(struct iosys_map 
*dst, size_t offset,
  * @offset__:  The offset from which to read
  * @type__:Type of the value being read
  *
- * Read a C type value from iosys_map, handling possible un-aligned accesses to
- * the mapping.
+ * Read a C type value (u8, u16, u32 and u64) from iosys_map. For other types 
or
+ * if pointer may be unaligned (and problematic for the architecture 
supported),
+ * use iosys_map_memcpy_from().
  *
  * Returns:
  * The value read from the mapping.
  */
-#define iosys_map_rd(map__, offset__, type__) ({   \
-   type__ val; \
-   iosys_map_memcpy_from(&val, map__, offset__, sizeof(val));  \
-   val;\
+#define iosys_map_rd(map__, offset__, type__) ({   
\
+   type__ val;

[PATCH 2/2] iosys-map: Add per-word write

2022-06-17 Thread Lucas De Marchi

Like was done for read, provide the equivalent for write. Even if
current users are not in the hot path, this should future-proof it.

v2:
  - Remove default from _Generic() - callers wanting to write more
than u64 should use iosys_map_memcpy_to()
  - Add WRITE_ONCE() cases dereferencing the pointer when using system
memory

Signed-off-by: Lucas De Marchi 
Reviewed-by: Reviewed-by: Christian König  # v1
---
 include/linux/iosys-map.h | 42 ++-
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index f59dd00ed202..580e14cd360c 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -337,9 +337,13 @@ static inline void iosys_map_memset(struct iosys_map *dst, 
size_t offset,
 #ifdef CONFIG_64BIT
 #define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) 
\
u64: val_ = readq(vaddr_iomem_)
+#define __iosys_map_wr_io_u64_case(val_, vaddr_iomem_) \
+   u64: writeq(val_, vaddr_iomem_)
 #else
 #define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) 
\
u64: memcpy_fromio(&(val_), vaddr_iomem__, sizeof(u64))
+#define __iosys_map_wr_io_u64_case(val_, vaddr_iomem_) \
+   u64: memcpy_toio(vaddr_iomem_, &(val_), sizeof(u64))
 #endif
 
 #define __iosys_map_rd_io(val__, vaddr_iomem__, type__) _Generic(val__,
\
@@ -354,6 +358,19 @@ static inline void iosys_map_memset(struct iosys_map *dst, 
size_t offset,
val__ = READ_ONCE(*((type__ *)vaddr__));
\
 })
 
+#define __iosys_map_wr_io(val__, vaddr_iomem__, type__) _Generic(val__,
\
+   u8: writeb(val__, vaddr_iomem__),   
\
+   u16: writew(val__, vaddr_iomem__),  
\
+   u32: writel(val__, vaddr_iomem__),  
\
+   __iosys_map_wr_io_u64_case(val__, vaddr_iomem__))
+
+#define __iosys_map_wr_sys(val__, vaddr__, type__) ({  
\
+   compiletime_assert(sizeof(type__) <= sizeof(u64),   
\
+  "Unsupported access size for __iosys_map_wr_sys()"); 
\
+   WRITE_ONCE(*((type__ *)vaddr__), val__);
\
+})
+
+
 /**
  * iosys_map_rd - Read a C-type value from the iosys_map
  *
@@ -386,12 +403,17 @@ static inline void iosys_map_memset(struct iosys_map 
*dst, size_t offset,
  * @type__:Type of the value being written
  * @val__: Value to write
  *
- * Write a C-type value to the iosys_map, handling possible un-aligned accesses
- * to the mapping.
+ * Write a C type value (u8, u16, u32 and u64) to the iosys_map. For other 
types
+ * or if pointer may be unaligned (and problematic for the architecture
+ * supported), use iosys_map_memcpy_to()
  */
-#define iosys_map_wr(map__, offset__, type__, val__) ({
\
-   type__ val = (val__);   \
-   iosys_map_memcpy_to(map__, offset__, &val, sizeof(val));\
+#define iosys_map_wr(map__, offset__, type__, val__) ({
\
+   type__ val = (val__);   
\
+   if ((map__)->is_iomem) {
\
+   __iosys_map_wr_io(val, (map__)->vaddr_iomem + (offset__), 
type__);\
+   } else {
\
+   __iosys_map_wr_sys(val, (map__)->vaddr + (offset__), type__);   
\
+   }   
\
 })
 
 /**
@@ -472,10 +494,12 @@ static inline void iosys_map_memset(struct iosys_map 
*dst, size_t offset,
  * @field__:   Member of the struct to read
  * @val__: Value to write
  *
- * Write a value to the iosys_map considering its layout is described by a C 
struct
- * starting at @struct_offset__. The field offset and size is calculated and 
the
- * @val__ is written handling possible un-aligned memory accesses. Refer to
- * iosys_map_rd_field() for expected usage and memory layout.
+ * Write a value to the iosys_map considering its layout is described by a C
+ * struct starting at @struct_offset__. The field offset and size is calculated
+ * and the @val__ is written. If the field access would incur in un-aligned
+ * access, then either iosys_map_memcpy_to() needs to be used or the
+ * architecture must support it. Refer to iosys_map_rd_field() for expected
+ * usage and memory layout.
  */
 #define iosys_map_wr_field(map__, struct_offset__, struct_type__, field__, 
val__) ({   \
struct_type__ *s;   
\
-- 
2.36.1

[PATCH] dma-buf: deprecate DMABUF_SYSFS_STATS

Add a warning that this UAPI wasn't such a good idea and shouldn't be
used by anybody.

That should give us a better chance to remove it at some point and
prevents others from running into the same issues.

Signed-off-by: Christian König 
---
 drivers/dma-buf/Kconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index 541efe01abc7..e4dc53a36428 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -75,7 +75,7 @@ menuconfig DMABUF_HEAPS
  between drivers.
 
 menuconfig DMABUF_SYSFS_STATS
-   bool "DMA-BUF sysfs statistics"
+   bool "DMA-BUF sysfs statistics (DEPRECATED)"
depends on DMA_SHARED_BUFFER
help
   Choose this option to enable DMA-BUF sysfs statistics
@@ -85,6 +85,10 @@ menuconfig DMABUF_SYSFS_STATS
   statistics for the DMA-BUF with the unique inode number
   .
 
+  This option is deprecated and should sooner or later be removed.
+  Android is the only user of this and it turned out that this resulted
+  in quite some performance problems.
+
 source "drivers/dma-buf/heaps/Kconfig"
 
 endmenu
-- 
2.25.1

Re: [PATCH v2 10/15] regulator: mt6370: Add mt6370 DisplayBias and VibLDO support

Hi Randy,

Thanks for your helpful comments!
We will refine them in the next patch, thanks!

Randy Dunlap  於 2022年6月14日 週二 凌晨4:15寫道：
>
>
>
> On 6/13/22 04:11, ChiaEn Wu wrote:
> > diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> > index cbe0f96ca342..dcb6866dab53 100644
> > --- a/drivers/regulator/Kconfig
> > +++ b/drivers/regulator/Kconfig
> > @@ -804,6 +804,14 @@ config REGULATOR_MT6360
> > 2-channel buck with Thermal Shutdown and Overload Protection
> > 6-channel High PSRR and Low Dropout LDO.
> >
> > +config REGULATOR_MT6370
> > + tristate "MT6370 SubPMIC Regulator"
> > + depends on MFD_MT6370
> > + help
> > +   Say Y here to enable MT6370 regulator support.
> > +   This driver support the control for DisplayBias voltages and one
>
>   supports
>
> > +   general purpose LDO which commonly used to drive the vibrator.
>
>   which is commonly used to drive the vibrator.
>
>
> --
> ~Randy

Best regards,
ChiaEn Wu

Re: [PATCH v2 11/15] iio: adc: mt6370: Add Mediatek MT6370 support

Hi Randy,

Thanks for your comment!
I apologize for any inconvenience caused when you decoded this help text.
I will refine this in the next patch, thanks!

Randy Dunlap  於 2022年6月14日 週二 凌晨4:17寫道：
>
> Hi,
>
> On 6/13/22 04:11, ChiaEn Wu wrote:
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 71ab0a06aa82..09576fb478ad 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -737,6 +737,15 @@ config MEDIATEK_MT6360_ADC
> > is used in smartphones and tablets and supports a 11 channel
> > general purpose ADC.
> >
> > +config MEDIATEK_MT6370_ADC
> > + tristate "Mediatek MT6370 ADC driver"
> > + depends on MFD_MT6370
> > + help
> > +   Say Y here to enable MT6370 ADC support.
> > +
> > +   Integrated for System Monitoring includes is used in smartphones
>
> Please try again on the help text. I can't decode that.
>
> > +   and tablets and supports a 9 channel general purpose ADC.
>
> --
> ~Randy

Best Regards,
ChiaEn Wu

Re: DRM FB interface does not sanitize len when mmap'ed


Hi

Am 15.06.22 um 17:00 schrieb Nuno Gonçalves:

I am crashing the kernel by doing something I believe I am allowed to do.

Using mmap to write to /dev/fb0 as the compatibility layer for Tiny
DRM vot,v220hf01a-t (ili9225).

First it happens that because of the display resolution of 220*176 the
buffer is (16 bit) 77440 bytes, which is not a multiple of the page
size (4096), unlike most regular resolution displays.

When I touch the mmap'ed virtual address above base+73728 (4096*18) up to 77439:

auto file = open("/dev/fb0", O_RDWR);
if (!file) throw;
auto fbp = (char *)mmap(0, 220 * 176 * 2, PROT_READ | PROT_WRITE,
MAP_SHARED, file, 0);
if ((size_t)fbp <= 0) throw;
fbp[220 * 176 * 2 - 2] = 0;

I get a crash:

[   14.150463] Unable to handle kernel paging request at virtual
address ffc00827c000
[   14.158640] Mem abort info:
[   14.161626]   ESR = 0x9607
[   14.164969]   EC = 0x25: DABT (current EL), IL = 32 bits
[   14.170470]   SET = 0, FnV = 0
[   14.173735]   EA = 0, S1PTW = 0
[   14.177047]   FSC = 0x07: level 3 translation fault
[   14.182095] Data abort info:
[   14.185083]   ISV = 0, ISS = 0x0007
[   14.189035]   CM = 0, WnR = 0
[   14.192107] swapper pgtable: 4k pages, 39-bit VAs, pgdp=00d54000
[   14.198997] [ffc00827c000] pgd=11501003,
p4d=11501003, pud=11501003, pmd=11d5c003,
pte=
[   14.211992] Internal error: Oops: 9607 [#1] PREEMPT SMP
[   14.217659] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 5.18.3 #18
[   14.224027] Hardware name: Raspberry Pi Compute Module 3 Plus Rev 1.0 (DT)
[   14.231005] Workqueue: events drm_fb_helper_damage_work
[   14.236333] pstate: 2005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   14.243405] pc : __memcpy+0x15c/0x230
[   14.247131] lr : drm_fb_helper_damage_work+0x25c/0x310
[   14.252352] sp : ffc00822bd30
[   14.255712] x29: ffc00822bd30 x28: 01b8 x27: ff80017e1d10
[   14.262970] x26: ffc008267e80 x25: 00b0 x24: ff8002416800
[   14.270228] x23: ff8001fd8080 x22: ff80017e1c00 x21: ff80017e1ccc
[   14.277487] x20: ffc00827be80 x19: ff80017e1cd0 x18: ffe5d80bac08
[   14.284745] x17: 0013 x16: 00fe72080e00 x15: 
[   14.292003] x14:  x13:  x12: 
[   14.299259] x11:  x10:  x9 : 
[   14.306517] x8 :  x7 :  x6 : 
[   14.313772] x5 : ffc008268038 x4 : ffc00827c038 x3 : ffc008267fc0
[   14.321029] x2 : 0028 x1 : ffc00827bfc0 x0 : ffc008267e80
[   14.328288] Call trace:
[   14.330766]  __memcpy+0x15c/0x230
[   14.334135]  process_one_work+0x1dc/0x450
[   14.338214]  worker_thread+0x300/0x450
[   14.342025]  kthread+0x100/0x110
[   14.345305]  ret_from_fork+0x10/0x20
[   14.348947] Code: a9422428 a9032c6a a9432c2a a984346c (a9c4342c)
[   14.355132] ---[ end trace  ]---

By constraining the input with this small patch it works fine:

--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -684,11 +684,13 @@ static void drm_fb_helper_damage(struct fb_info
*info, u32 x, u32 y,
  static void drm_fb_helper_memory_range_to_clip(struct fb_info *info,
off_t off, size_t len,
struct drm_rect *clip)
  {
+   struct drm_fb_helper *fb_helper = info->par;
+
 off_t end = off + len;
 u32 x1 = 0;
 u32 y1 = off / info->fix.line_length;
 u32 x2 = info->var.xres;
-   u32 y2 = DIV_ROUND_UP(end, info->fix.line_length);
+   u32 y2 = min_t(u32, DIV_ROUND_UP(end, info->fix.line_length),
fb_helper->fb->height);

 if ((y2 - y1) == 1) {
 /*

I am sure this patch is not how it should be fixed, but I have no
knowledge of the subsystem to fix it "at the right place".


Thank you so much for reporting this bug and indicating the cause. Your 
fix is actually quite close. Because each scanline is rather short, the 
final page has a lot of empty memory. Hence, the damage handler

computes non-existing scanlines that need to be updated.

Could you please try the attached patch? It's similar to your solution, 
but closer to the original intention of the code.


Best regards
Thomas



Thanks,
Nuno


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
From e1e3bfe7bd74d5c4cfab15e05a56088d5edf82ce Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann 
Date: Fri, 17 Jun 2022 11:01:41 +0200
Subject: [PATCH] drm/fb-helper: Fix out-of-bounds access
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Clip memory range to screen-buffer size to avoid out-of-bounds access
in fbdev deferred I/O's damage handling.

Fbdev's deferred I/O can only track pages. Fro

[PATCH] drm/connector: Remove usage of the deprecated ida_simple_xxx API

2022-06-17 Thread Bo Liu

Use ida_alloc_xxx()/ida_free() instead of
ida_simple_get()/ida_simple_remove().
The latter is deprecated and more verbose.

Signed-off-by: Bo Liu 
---
 drivers/gpu/drm/drm_connector.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1c48d162c77e..cfba71724f84 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -250,7 +250,7 @@ int drm_connector_init(struct drm_device *dev,
connector->funcs = funcs;
 
/* connector index is used with 32bit bitmasks */
-   ret = ida_simple_get(&config->connector_ida, 0, 32, GFP_KERNEL);
+   ret = ida_alloc_max(&config->connector_ida, 31, GFP_KERNEL);
if (ret < 0) {
DRM_DEBUG_KMS("Failed to allocate %s connector index: %d\n",
  drm_connector_enum_list[connector_type].name,
@@ -262,7 +262,7 @@ int drm_connector_init(struct drm_device *dev,
 
connector->connector_type = connector_type;
connector->connector_type_id =
-   ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
+   ida_alloc_min(connector_ida, 1, GFP_KERNEL);
if (connector->connector_type_id < 0) {
ret = connector->connector_type_id;
goto out_put_id;
@@ -322,10 +322,10 @@ int drm_connector_init(struct drm_device *dev,
connector->debugfs_entry = NULL;
 out_put_type_id:
if (ret)
-   ida_simple_remove(connector_ida, connector->connector_type_id);
+   ida_free(connector_ida, connector->connector_type_id);
 out_put_id:
if (ret)
-   ida_simple_remove(&config->connector_ida, connector->index);
+   ida_free(&config->connector_ida, connector->index);
 out_put:
if (ret)
drm_mode_object_unregister(dev, &connector->base);
@@ -479,11 +479,10 @@ void drm_connector_cleanup(struct drm_connector 
*connector)
list_for_each_entry_safe(mode, t, &connector->modes, head)
drm_mode_remove(connector, mode);
 
-   
ida_simple_remove(&drm_connector_enum_list[connector->connector_type].ida,
+   ida_free(&drm_connector_enum_list[connector->connector_type].ida,
  connector->connector_type_id);
 
-   ida_simple_remove(&dev->mode_config.connector_ida,
- connector->index);
+   ida_free(&dev->mode_config.connector_ida, connector->index);
 
kfree(connector->display_info.bus_formats);
drm_mode_object_unregister(dev, &connector->base);
-- 
2.27.0

Re: [PATCH v2 15/15] video: backlight: mt6370: Add Mediatek MT6370 support

Hi Daniel,

Thanks for your helpful feedback!

Daniel Thompson  於 2022年6月14日 週二 凌晨1:08寫道：
>
> On Mon, Jun 13, 2022 at 07:11:46PM +0800, ChiaEn Wu wrote:
> > +static int mt6370_init_backlight_properties(struct mt6370_priv *priv,
> > + struct backlight_properties 
> > *props)
>
> Most of the changes in this version looks good... but it looks the new
> code in this function has a number of problems. See below...
>
>
> > +{
> > + struct device *dev = priv->dev;
> > + u8 prop_val;
> > + u32 brightness;
> > + unsigned int mask, val;
> > + int ret;
> > +
> > + /* Vendor optional properties
> > +  * if property not exist, keep value in default.
> > +  */
>
> That's not the right strategy for booleans. Not existing means false
> (e.g. flags should actively be unset).
>

I am so sorry for making these mistakes...
I will try to refine them in the right strategy in the next patch!

>
> > + if (device_property_read_bool(dev, "mediatek,bled-pwm-enable")) {
> > + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_PWM,
> > +  MT6370_BL_PWM_EN_MASK,
> > +  MT6370_BL_PWM_EN_MASK);
> > + if (ret)
> > + return ret;
> > + }
>
> As above comment... all of the boolean properties are now being read
> incorrectly.
>
>
> > +
> > + if (device_property_read_bool(dev, "mediatek,bled-pwm-hys-enable")) {
> > + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_PWM,
> > +  MT6370_BL_PWM_HYS_EN_MASK,
> > +  MT6370_BL_PWM_HYS_EN_MASK);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + ret = device_property_read_u8(dev, "mediatek,bled-pwm-hys-input-bit",
> > +   &prop_val);
> > + if (!ret) {
> > + val = min_t(u8, prop_val, 3)
> > +   << (ffs(MT6370_BL_PWM_HYS_SEL_MASK) - 1);
> > + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_PWM,
> > +  MT6370_BL_PWM_HYS_SEL_MASK, val);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + ret = device_property_read_u8(dev, "mediatek,bled-ovp-microvolt",
> > +   &prop_val);
> > + if (!ret) {
> > + val = min_t(u8, prop_val, 3)
> > +   << (ffs(MT6370_BL_OVP_SEL_MASK) - 1);
>
> This has been renamed but still seems to the using 0, 1, 2, 3 rather
> than an actual value in microvolts.

I’m so sorry for using the not actual value in microvolts and microamps.
I will refine these mistakes along with DT in the next patch. Thank you!

>
>
> > + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_BSTCTRL,
> > +  MT6370_BL_OVP_SEL_MASK, val);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (device_property_read_bool(dev, "mediatek,bled-ovp-shutdown")) {
> > + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_BSTCTRL,
> > +  MT6370_BL_OVP_EN_MASK,
> > +  MT6370_BL_OVP_EN_MASK);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + ret = device_property_read_u8(dev, "mediatek,bled-ocp-microamp",
> > +   &prop_val);
> > + if (!ret) {
> > + val = min_t(u8, prop_val, 3)
> > +   << (ffs(MT6370_BL_OC_SEL_MASK) - 1);
>
> Likewise, should this be accepting a value in microamps?
>
>
> > + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_BSTCTRL,
> > +  MT6370_BL_OC_SEL_MASK, val);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (device_property_read_bool(dev, "mediatek,bled-ocp-shutdown")) {
> > + ret = regmap_update_bits(priv->regmap, MT6370_REG_BL_BSTCTRL,
> > +  MT6370_BL_OC_EN_MASK,
> > +  MT6370_BL_OC_EN_MASK);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + /* Common properties */
> > + ret = device_property_read_u32(dev, "max-brightness", &brightness);
> > + if (ret)
> > + brightness = MT6370_BL_MAX_BRIGHTNESS;
> > +
> > + props->max_brightness = min_t(u32, brightness,
> > +   MT6370_BL_MAX_BRIGHTNESS);
> > +
> > + ret = device_property_read_u32(dev, "default-brightness", 
> > &brightness);
> > + if (ret)
> > + brightness = props->max_brightness;
> > +
> > + props->brightness = min_t(u32, brightness, props->max_brightness);
> > +
> > +
> > + ret = device_property_read_u8(dev, "mediatek,bled

RE: [Intel-gfx] [PATCH v2 7/9] drm/i915/rpm: Enable D3Cold VRAM SR Support

2022-06-17 Thread Gupta, Anshuman




> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, June 16, 2022 8:02 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Wilson, Chris P ; Vivi, Rodrigo
> 
> Subject: Re: [Intel-gfx] [PATCH v2 7/9] drm/i915/rpm: Enable D3Cold VRAM SR
> Support
> 
> On Thu, 16 Jun 2022, Anshuman Gupta  wrote:
> > Intel Client DGFX card supports D3Cold with two option.
> > D3Cold-off zero watt, D3Cold-VRAM Self Refresh.
> >
> > i915 requires to evict the lmem objects to smem in order to support
> > D3Cold-Off, which increases i915 the suspend/resume latency. Enabling
> > VRAM Self Refresh feature optimize the latency with additional power
> > cost which required to retain the lmem.
> >
> > Adding intel_runtime_idle (runtime_idle callback) to enable VRAM_SR,
> > it will be used for policy to choose between D3Cold-off vs
> > D3Cold-VRAM_SR.
> >
> > Since we have introduced i915 runtime_idle callback.
> > It need to be warranted that Runtime PM Core invokes runtime_idle
> > callback when runtime usages count becomes zero. That requires to use
> > pm_runtime_put instead of pm_runtime_put_autosuspend.
> >
> > TODO: GuC interface state save/restore.
> >
> > Cc: Rodrigo Vivi 
> > Cc: Chris Wilson 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/gpu/drm/i915/i915_driver.c  | 26 +
> >  drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +--
> >  2 files changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index aa1fb15b1f11..fcff5f3fe05e 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -1557,6 +1557,31 @@ static int i915_pm_restore(struct device *kdev)
> > return i915_pm_resume(kdev);
> >  }
> >
> > +static int intel_runtime_idle(struct device *kdev) {
> > +   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> > +   int ret = 1;
> > +
> > +   if (!HAS_LMEM_SR(dev_priv)) {
> > +   /*TODO: Prepare for D3Cold-Off */
> > +   goto out;
> > +   }
> > +
> > +   disable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> > +
> > +   ret = intel_pm_vram_sr(dev_priv, true);
> > +   if (!ret)
> > +   drm_dbg(&dev_priv->drm, "VRAM Self Refresh enabled\n");
> 
> Please add the debug in the intel_pm_vram_sr() function instead.
Thanks for review comment, will fix this.
Regards,
Anshuman Gupta.
> 
> BR,
> Jani.
> 
> > +
> > +   enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
> > +
> > +out:
> > +   pm_runtime_mark_last_busy(kdev);
> > +   pm_runtime_autosuspend(kdev);
> > +
> > +   return ret;
> > +}
> > +
> >  static int intel_runtime_suspend(struct device *kdev)  {
> > struct drm_i915_private *dev_priv = kdev_to_i915(kdev); @@ -1742,6
> > +1767,7 @@ const struct dev_pm_ops i915_pm_ops = {
> > .restore = i915_pm_restore,
> >
> > /* S0ix (via runtime suspend) event handlers */
> > +   .runtime_idle = intel_runtime_idle,
> > .runtime_suspend = intel_runtime_suspend,
> > .runtime_resume = intel_runtime_resume,  }; diff --git
> > a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 6ed5786bcd29..4dade7e8a795 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -492,8 +492,7 @@ static void __intel_runtime_pm_put(struct
> > intel_runtime_pm *rpm,
> >
> > intel_runtime_pm_release(rpm, wakelock);
> >
> > -   pm_runtime_mark_last_busy(kdev);
> > -   pm_runtime_put_autosuspend(kdev);
> > +   pm_runtime_put(kdev);
> >  }
> >
> >  /**
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v5 01/13] mm: add zone device coherent type memory support

On 31.05.22 22:00, Alex Sierra wrote:
> Device memory that is cache coherent from device and CPU point of view.
> This is used on platforms that have an advanced system bus (like CAPI
> or CXL). Any page of a process can be migrated to such memory. However,
> no one should be allowed to pin such memory so that it can always be
> evicted.
> 
> Signed-off-by: Alex Sierra 
> Acked-by: Felix Kuehling 
> Reviewed-by: Alistair Popple 
> [hch: rebased ontop of the refcount changes,
>   removed is_dev_private_or_coherent_page]
> Signed-off-by: Christoph Hellwig 
> ---
>  include/linux/memremap.h | 19 +++
>  mm/memcontrol.c  |  7 ---
>  mm/memory-failure.c  |  8 ++--
>  mm/memremap.c| 10 ++
>  mm/migrate_device.c  | 16 +++-
>  mm/rmap.c|  5 +++--
>  6 files changed, 49 insertions(+), 16 deletions(-)
> 
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 8af304f6b504..9f752ebed613 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -41,6 +41,13 @@ struct vmem_altmap {
>   * A more complete discussion of unaddressable memory may be found in
>   * include/linux/hmm.h and Documentation/vm/hmm.rst.
>   *
> + * MEMORY_DEVICE_COHERENT:
> + * Device memory that is cache coherent from device and CPU point of view. 
> This
> + * is used on platforms that have an advanced system bus (like CAPI or CXL). 
> A
> + * driver can hotplug the device memory using ZONE_DEVICE and with that 
> memory
> + * type. Any page of a process can be migrated to such memory. However no one

Any page might not be right, I'm pretty sure. ... just thinking about special 
pages
like vdso, shared zeropage, ... pinned pages ...

> + * should be allowed to pin such memory so that it can always be evicted.
> + *
>   * MEMORY_DEVICE_FS_DAX:
>   * Host memory that has similar access semantics as System RAM i.e. DMA
>   * coherent and supports page pinning. In support of coordinating page
> @@ -61,6 +68,7 @@ struct vmem_altmap {
>  enum memory_type {
>   /* 0 is reserved to catch uninitialized type fields */
>   MEMORY_DEVICE_PRIVATE = 1,
> + MEMORY_DEVICE_COHERENT,
>   MEMORY_DEVICE_FS_DAX,
>   MEMORY_DEVICE_GENERIC,
>   MEMORY_DEVICE_PCI_P2PDMA,
> @@ -143,6 +151,17 @@ static inline bool folio_is_device_private(const struct 
> folio *folio)

In general, this LGTM, and it should be correct with PageAnonExclusive I think.


However, where exactly is pinning forbidden?

-- 
Thanks,

David / dhildenb

RE: [PATCH v2 1/9] drm/i915/dgfx: OpRegion VRAM Self Refresh Support

2022-06-17 Thread Gupta, Anshuman




> -Original Message-
> From: Nikula, Jani 
> Sent: Thursday, June 16, 2022 6:26 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Roper, Matthew D ; Nilawar, Badal
> ; Ewins, Jon ; Vivi, Rodrigo
> ; Ursulin, Tvrtko ; Tangudu,
> Tilak ; Gupta, Anshuman
> 
> Subject: Re: [PATCH v2 1/9] drm/i915/dgfx: OpRegion VRAM Self Refresh
> Support
> 
> On Thu, 16 Jun 2022, Anshuman Gupta  wrote:
> > Intel DGFX cards provides a feature Video Ram Self Refrsh(VRSR).
> > DGFX VRSR can be enabled with runtime suspend D3Cold flow and with
> > opportunistic S0ix system wide suspend flow as well.
> >
> > Without VRSR enablement i915 has to evict the lmem objects to system
> > memory. Depending on some heuristics driver will evict lmem objects
> > without VRSR.
> >
> > VRSR feature requires Host BIOS support, VRSR will be enable/disable
> > by HOST BIOS using ACPI OpRegion.
> >
> > Adding OpRegion VRSR support in order to enable/disable VRSR on
> > discrete cards.
> >
> > BSpec: 53440
> > Cc: Jani Nikula 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Anshuman Gupta 
> > ---
> >  drivers/gpu/drm/i915/display/intel_opregion.c | 62
> > ++-  drivers/gpu/drm/i915/display/intel_opregion.h |
> > 11 
> >  2 files changed, 72 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> > b/drivers/gpu/drm/i915/display/intel_opregion.c
> > index 6876ba30d5a9..11d8c5bb23ac 100644
> > --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> > +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> > @@ -53,6 +53,8 @@
> >  #define MBOX_ASLE_EXT  BIT(4)  /* Mailbox #5 */
> >  #define MBOX_BACKLIGHT BIT(5)  /* Mailbox #2 (valid from v3.x)
> */
> >
> > +#define PCON_DGFX_BIOS_SUPPORTS_VRSR   BIT(11)
> > +#define PCON_DGFX_BIOS_SUPPORTS_VRSR_FIELD_VALID   BIT(12)
> >  #define PCON_HEADLESS_SKU  BIT(13)
> >
> >  struct opregion_header {
> > @@ -130,7 +132,8 @@ struct opregion_asle {
> > u64 rvda;   /* Physical (2.0) or relative from opregion (2.1+)
> >  * address of raw VBT data. */
> > u32 rvds;   /* Size of raw vbt data */
> > -   u8 rsvd[58];
> > +   u8 vrsr;/* DGFX Video Ram Self Refresh */
> > +   u8 rsvd[57];
> >  } __packed;
> >
> >  /* OpRegion mailbox #5: ASLE ext */
> > @@ -201,6 +204,9 @@ struct opregion_asle_ext {
> >
> >  #define ASLE_PHED_EDID_VALID_MASK  0x3
> >
> > +/* VRAM SR */
> > +#define ASLE_VRSR_ENABLE   BIT(0)
> > +
> >  /* Software System Control Interrupt (SWSCI) */
> >  #define SWSCI_SCIC_INDICATOR   (1 << 0)
> >  #define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
> > @@ -921,6 +927,8 @@ int intel_opregion_setup(struct drm_i915_private
> *dev_priv)
> > opregion->header->over.minor,
> > opregion->header->over.revision);
> >
> > +   drm_dbg(&dev_priv->drm, "OpRegion PCON values 0x%x\n",
> > +opregion->header->pcon);
> > +
> > mboxes = opregion->header->mboxes;
> > if (mboxes & MBOX_ACPI) {
> > drm_dbg(&dev_priv->drm, "Public ACPI methods supported\n");
> @@
> > -1246,3 +1254,55 @@ void intel_opregion_unregister(struct drm_i915_private
> *i915)
> > opregion->vbt = NULL;
> > opregion->lid_state = NULL;
> >  }
> > +
> > +/**
> > + * intel_opregion_bios_supports_vram_sr() get HOST BIOS VRAM Self
> > + * Refresh capability support.
> > + * @i915: pointer to i915 device.
> > + *
> > + * It checks opregion pcon vram_sr fields to get HOST BIOS vram_sr
> > + * capability support. It is only applocable to DGFX.
> > + *
> > + * Returns:
> > + * true when bios supports vram_sr, or false if bios doesn't support.
> > + */
> > +bool intel_opregion_bios_supports_vram_sr(struct drm_i915_private
> > +*i915) {
> > +   struct intel_opregion *opregion = &i915->opregion;
> > +
> > +   if (!IS_DGFX(i915))
> > +   return false;
> > +
> > +   if (!opregion)
> 
> This is always true. You should check for !opregion->header.
> 
> > +   return false;
> > +
> > +   if (opregion->header->pcon &
> PCON_DGFX_BIOS_SUPPORTS_VRSR_FIELD_VALID)
> > +   return opregion->header->pcon &
> PCON_DGFX_BIOS_SUPPORTS_VRSR;
> > +   else
> > +   return false;
> > +}
> > +
> > +/**
> > + * intel_opregion_vram_sr() - enable/disable VRAM Self Refresh.
> > + * @i915: pointer to i915 device.
> > + * @enable: Argument to enable/disable VRSR.
> > + *
> > + * It enables/disables vram_sr in opregion ASLE MBOX, based upon that
> > + * HOST BIOS will enables and disbales VRAM_SR during
> > + * ACPI _PS3/_OFF and _PS/_ON glue method.
> > + */
> > +void intel_opregion_vram_sr(struct drm_i915_private *i915, bool
> > +enable) {
> > +   struct intel_opregion *opregion = &i915->opregion;
> > +
> > +   if (!opregion)
> 
> Same as above.
> 
> > +   return;
> > +
> > +   if (drm_WARN(&i915->drm, !opregion->asle, "ASLE MAILBOX3 is not
> available\n"))
> > +   return;
> 
> I'd just b

Re: [PATCH v5 02/13] mm: handling Non-LRU pages returned by vm_normal_pages

On 31.05.22 22:00, Alex Sierra wrote:
> With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
> device-managed anonymous pages that are not LRU pages. Although they
> behave like normal pages for purposes of mapping in CPU page, and for
> COW. They do not support LRU lists, NUMA migration or THP.
> 
> We also introduced a FOLL_LRU flag that adds the same behaviour to
> follow_page and related APIs, to allow callers to specify that they
> expect to put pages on an LRU list.
> 
> Signed-off-by: Alex Sierra 
> Acked-by: Felix Kuehling 
> ---
>  fs/proc/task_mmu.c | 2 +-
>  include/linux/mm.h | 3 ++-
>  mm/gup.c   | 6 +-
>  mm/huge_memory.c   | 2 +-
>  mm/khugepaged.c| 9 ++---
>  mm/ksm.c   | 6 +++---
>  mm/madvise.c   | 4 ++--
>  mm/memory.c| 9 -
>  mm/mempolicy.c | 2 +-
>  mm/migrate.c   | 4 ++--
>  mm/mlock.c | 2 +-
>  mm/mprotect.c  | 2 +-
>  12 files changed, 33 insertions(+), 18 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 2d04e3470d4c..2dd8c8a66924 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1792,7 +1792,7 @@ static struct page *can_gather_numa_stats(pte_t pte, 
> struct vm_area_struct *vma,
>   return NULL;
>  
>   page = vm_normal_page(vma, addr, pte);
> - if (!page)
> + if (!page || is_zone_device_page(page))
>   return NULL;
>  
>   if (PageReserved(page))
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index bc8f326be0ce..d3f43908ff8d 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -601,7 +601,7 @@ struct vm_operations_struct {
>  #endif
>   /*
>* Called by vm_normal_page() for special PTEs to find the
> -  * page for @addr.  This is useful if the default behavior
> +  * page for @addr. This is useful if the default behavior
>* (using pte_page()) would not find the correct page.
>*/
>   struct page *(*find_special_page)(struct vm_area_struct *vma,
> @@ -2934,6 +2934,7 @@ struct page *follow_page(struct vm_area_struct *vma, 
> unsigned long address,
>  #define FOLL_NUMA0x200   /* force NUMA hinting page fault */
>  #define FOLL_MIGRATION   0x400   /* wait for page to replace migration 
> entry */
>  #define FOLL_TRIED   0x800   /* a retry, previous pass started an IO */
> +#define FOLL_LRU0x1000  /* return only LRU (anon or page cache) */

Does that statement hold for special pages like the shared zeropage?

Also, this flag is only valid for in-kernel follow_page() but not for
the ordinary GUP interfaces. What are the semantics there? Is it fenced?


I really wonder if you should simply similarly teach the handful of
users of follow_page() to just special case these pages ... sounds
cleaner to me then adding flags with unclear semantics. Alternatively,
properly document what that flag is actually doing and where it applies.


I know, there was discussion on ... sorry for jumping in now, but this
doesn't look clean to me yet.

-- 
Thanks,

David / dhildenb

Re: [PATCH v2 2/3] drm/panel: panel-dsi-cm: Use backlight helpers

2022-06-17 Thread Sebastian Reichel

Hi,

On Thu, Jun 16, 2022 at 07:23:14PM +0200, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from future changes.
> 
> Instead of setting the power state by manually updating fields in
> struct backlight_properties, use backlight_enable() and
> backlight_disable(). These also call backlight_update_status() so the
> separate call is no longer needed.
> 
> Signed-off-by: Stephen Kitt 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> ---
> Changes since v1: removed unnecessary parentheses
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-dsi-cm.c | 29 ++--
>  1 file changed, 6 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-dsi-cm.c 
> b/drivers/gpu/drm/panel/panel-dsi-cm.c
> index b58cb064975f..b0213a518f9d 100644
> --- a/drivers/gpu/drm/panel/panel-dsi-cm.c
> +++ b/drivers/gpu/drm/panel/panel-dsi-cm.c
> @@ -85,17 +85,10 @@ static void dsicm_bl_power(struct panel_drv_data *ddata, 
> bool enable)
>   else
>   return;
>  
> - if (enable) {
> - backlight->props.fb_blank = FB_BLANK_UNBLANK;
> - backlight->props.state = ~(BL_CORE_FBBLANK | BL_CORE_SUSPENDED);
> - backlight->props.power = FB_BLANK_UNBLANK;
> - } else {
> - backlight->props.fb_blank = FB_BLANK_NORMAL;
> - backlight->props.power = FB_BLANK_POWERDOWN;
> - backlight->props.state |= BL_CORE_FBBLANK | BL_CORE_SUSPENDED;
> - }
> -
> - backlight_update_status(backlight);
> + if (enable)
> + backlight_enable(backlight);
> + else
> + backlight_disable(backlight);
>  }
>  
>  static void hw_guard_start(struct panel_drv_data *ddata, int guard_msec)
> @@ -196,13 +189,7 @@ static int dsicm_bl_update_status(struct 
> backlight_device *dev)
>  {
>   struct panel_drv_data *ddata = dev_get_drvdata(&dev->dev);
>   int r = 0;
> - int level;
> -
> - if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
> - dev->props.power == FB_BLANK_UNBLANK)
> - level = dev->props.brightness;
> - else
> - level = 0;
> + int level = backlight_get_brightness(dev);
>  
>   dev_dbg(&ddata->dsi->dev, "update brightness to %d\n", level);
>  
> @@ -219,11 +206,7 @@ static int dsicm_bl_update_status(struct 
> backlight_device *dev)
>  
>  static int dsicm_bl_get_intensity(struct backlight_device *dev)
>  {
> - if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
> - dev->props.power == FB_BLANK_UNBLANK)
> - return dev->props.brightness;
> -
> - return 0;
> + return backlight_get_brightness(dev);
>  }
>  
>  static const struct backlight_ops dsicm_bl_ops = {
> -- 
> 2.30.2
> 


signature.asc
Description: PGP signature

Re: [PATCH v2 3/3] drm/panel: sony-acx565akm: Use backlight helpers

2022-06-17 Thread Sebastian Reichel

Hi,

On Thu, Jun 16, 2022 at 07:23:15PM +0200, Stephen Kitt wrote:
> Instead of retrieving the backlight brightness in struct
> backlight_properties manually, and then checking whether the backlight
> should be on at all, use backlight_get_brightness() which does all
> this and insulates this from future changes.
> 
> Instead of manually checking the power state in struct
> backlight_properties, use backlight_is_blank().
> 
> While we're at it, drop .fb_blank from the initialisation function; it
> is deprecated, and this helps make progress towards enabling its
> removal. This change makes no functional difference since
> FB_BLANK_UNBLANK is the default value.
> 
> Signed-off-by: Stephen Kitt 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: dri-devel@lists.freedesktop.org
> ---
> Changes since v1: removed the last remaining .fb_blank reference
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

>  drivers/gpu/drm/panel/panel-sony-acx565akm.c | 12 ++--
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c 
> b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> index 0d7541a33f87..3d6a286056a0 100644
> --- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> +++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
> @@ -298,13 +298,7 @@ static void acx565akm_set_brightness(struct 
> acx565akm_panel *lcd, int level)
>  static int acx565akm_bl_update_status_locked(struct backlight_device *dev)
>  {
>   struct acx565akm_panel *lcd = dev_get_drvdata(&dev->dev);
> - int level;
> -
> - if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
> - dev->props.power == FB_BLANK_UNBLANK)
> - level = dev->props.brightness;
> - else
> - level = 0;
> + int level = backlight_get_brightness(dev);
>  
>   acx565akm_set_brightness(lcd, level);
>  
> @@ -330,8 +324,7 @@ static int acx565akm_bl_get_intensity(struct 
> backlight_device *dev)
>  
>   mutex_lock(&lcd->mutex);
>  
> - if (dev->props.fb_blank == FB_BLANK_UNBLANK &&
> - dev->props.power == FB_BLANK_UNBLANK)
> + if (!backlight_is_blank(dev))
>   intensity = acx565akm_get_actual_brightness(lcd);
>   else
>   intensity = 0;
> @@ -349,7 +342,6 @@ static const struct backlight_ops acx565akm_bl_ops = {
>  static int acx565akm_backlight_init(struct acx565akm_panel *lcd)
>  {
>   struct backlight_properties props = {
> - .fb_blank = FB_BLANK_UNBLANK,
>   .power = FB_BLANK_UNBLANK,
>   .type = BACKLIGHT_RAW,
>   };
> -- 
> 2.30.2
> 


signature.asc
Description: PGP signature

Re: [PATCH] drm/i915: Improve on suspend / resume time with VT-d enabled

2022-06-17 Thread Matthew Auld


On 05/04/2022 11:59, Thomas Hellström wrote:

When DMAR / VT-d is enabled, the display engine uses overfetching,
presumably to deal with the increased latency. To avoid display engine
errors and DMAR faults, as a workaround the GGTT is populated with scatch
PTEs when VT-d is enabled. However starting with gen10, Write-combined
writing of scratch PTES is no longer possible and as a result, populating
the full GGTT with scratch PTEs like on resume becomes very slow as
uncached access is needed.

Therefore, on integrated GPUs utilize the fact that the PTEs are stored in
stolen memory which retain content across S3 suspend. Don't clear the PTEs
on suspend and resume. This improves on resume time with around 100 ms.
While 100+ms might appear like a short time it's 10% to 20% of total resume
time and important in some applications.

One notable exception is Intel Rapid Start Technology which may cause
stolen memory to be lost across what the OS percieves as S3 suspend.
If IRST is enabled or if we can't detect whether IRST is enabled, retain
the old workaround, clearing and re-instating PTEs.

As an additional measure, if we detect that the last ggtt pte was lost
during suspend, print a warning and re-populate the GGTT ptes

On discrete GPUs, the display engine scans out from LMEM which isn't
subject to DMAR, and presumably the workaround is therefore not needed,
but that needs to be verified and disabling the workaround for dGPU,
if possible, will be deferred to a follow-up patch.

v2:
- Rely on retained ptes to also speed up suspend and resume re-binding.
- Re-build GGTT ptes if Intel rst is enabled.
v3:
- Re-build GGTT ptes also if we can't detect whether Intel rst is enabled,
   and if the guard page PTE and end of GGTT was lost.

Signed-off-by: Thomas Hellström 
---
  drivers/gpu/drm/i915/gt/intel_ggtt.c | 56 +---
  drivers/gpu/drm/i915/gt/intel_gtt.h  | 20 ++
  drivers/gpu/drm/i915/i915_driver.c   | 16 
  3 files changed, 86 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 04191fe2ee34..98441b1c1b75 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -23,6 +23,13 @@
  #include "intel_gtt.h"
  #include "gen8_ppgtt.h"
  
+static inline bool suspend_retains_ptes(struct i915_address_space *vm)

+{
+   return GRAPHICS_VER(vm->i915) >= 8 &&
+   !HAS_LMEM(vm->i915) &&
+   vm->is_ggtt;
+}
+
  static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
   unsigned long color,
   u64 *start,
@@ -116,6 +123,23 @@ static bool needs_idle_maps(struct drm_i915_private *i915)
return false;
  }
  
+/*

+ * Return the value of the last GGTT pte cast to an u64, if
+ * the system is supposed to retain ptes across resume. 0 otherwise.
+ */
+static u64 read_last_pte(struct i915_address_space *vm)
+{
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
+   gen8_pte_t __iomem *ptep;
+
+   if (!suspend_retains_ptes(vm))
+   return 0;
+
+   GEM_BUG_ON(GRAPHICS_VER(vm->i915) < 8);
+   ptep = (typeof(ptep))ggtt->gsm + (ggtt_total_entries(ggtt) - 1);
+   return readq(ptep);
+}
+
  /**
   * i915_ggtt_suspend_vm - Suspend the memory mappings for a GGTT or DPT VM
   * @vm: The VM to suspend the mappings for
@@ -179,7 +203,10 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
i915_gem_object_unlock(obj);
}
  
-	vm->clear_range(vm, 0, vm->total);

+   if (!suspend_retains_ptes(vm))
+   vm->clear_range(vm, 0, vm->total);
+   else
+   i915_vm_to_ggtt(vm)->probed_pte = read_last_pte(vm);
  
  	vm->skip_pte_rewrite = save_skip_rewrite;
  
@@ -578,6 +605,8 @@ static int init_ggtt(struct i915_ggtt *ggtt)

struct drm_mm_node *entry;
int ret;
  
+	ggtt->pte_lost = true;

+
/*
 * GuC requires all resources that we're sharing with it to be placed in
 * non-WOPCM memory. If GuC is not present or not in use we still need a
@@ -1309,11 +1338,20 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
  {
struct i915_vma *vma;
bool write_domain_objs = false;
+   bool retained_ptes;
  
  	drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
  
-	/* First fill our portion of the GTT with scratch pages */

-   vm->clear_range(vm, 0, vm->total);
+   /*
+* First fill our portion of the GTT with scratch pages if
+* they were not retained across suspend.
+*/
+   retained_ptes = suspend_retains_ptes(vm) &&
+   !i915_vm_to_ggtt(vm)->pte_lost &&
+   !GEM_WARN_ON(i915_vm_to_ggtt(vm)->probed_pte != 
read_last_pte(vm));
+
+   if (!retained_ptes)
+   vm->clear_range(vm, 0, vm->total);
  
  	/* clflush objects bound into the GGTT and rebind them. */

list_for_

Re: [PATCH v2 02/15] dt-bindings: power: supply: Add Mediatek MT6370 Charger

Hi Krzysztof,

Thanks for your helpful comments! I have so some questions want to ask
you below.

Krzysztof Kozlowski  於 2022年6月17日 週五 清晨5:05寫道：
>
> On 13/06/2022 04:11, ChiaEn Wu wrote:
> > From: ChiaEn Wu 
> >
> > Add Mediatek MT6370 Charger binding documentation.
> >
> > Signed-off-by: ChiaEn Wu 
> > ---
> >  .../power/supply/mediatek,mt6370-charger.yaml | 60 +++
> >  1 file changed, 60 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml
> >  
> > b/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml
> > new file mode 100644
> > index ..b63553ebb15b
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/power/supply/mediatek,mt6370-charger.yaml
> > @@ -0,0 +1,60 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: 
> > http://devicetree.org/schemas/power/supply/mediatek,mt6370-charger.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mediatek MT6370 Battery Charger
> > +
> > +maintainers:
> > +  - ChiaEn Wu 
> > +
> > +description: |
> > +  This module is part of the MT6370 MFD device.
> > +  Provides Battery Charger, Boost for OTG devices and BC1.2 detection.
> > +
> > +properties:
> > +  compatible:
> > +const: mediatek,mt6370-charger
> > +
> > +  interrupts:
> > +description: |
> > +  Specify what irqs are needed to be handled by MT6370 Charger driver. 
> > IRQ
> > +  "MT6370_IRQ_CHG_MIVR", "MT6370_IRQ_ATTACH" and 
> > "MT6370_IRQ_OVPCTRL_UVP_D"
> > +  are required.
> > +items:
> > +  - description: BC1.2 done irq
> > +  - description: usb plug in irq
> > +  - description: mivr irq
> > +
> > +  interrupt-names:
> > +items:
> > +  - const: attach_i
> > +  - const: uvp_d_evt
> > +  - const: mivr
> > +
> > +  io-channels:
> > +description: |
> > +  Use ADC channel to read vbus, ibus, ibat, etc., info. Ibus ADC 
> > channel
> > +  is required.
>
> Add io-channel-names and describe each item - what type of ADC it is
> expected to be.
>

I'm afraid I might not be understanding what you mean.
I will try to add some text in "description" and "io-channel-names", like below
--
io-channels:
  description: |
Use ADC channel to read VBUS, IBUS, IBAT, etc., info. Ibus ADC channel
is required. It can be seen in
include/dt-bindings/iio/adc/mediatek,mt6370_adc.h
  minItems: 1
  maxItems: 9

io-channel-names:
  items:
- const: vbusdiv5
- const: vbusdiv2
- ...
--
Did these modifications meet your expectations?

> > +minItems: 1
> > +maxItems: 9
> > +
> > +  usb-otg-vbus-regulator:
> > +type: object
> > +description: OTG boost regulator.
> > +$ref: /schemas/regulator/regulator.yaml#
>
> unevaluatedProperties: false

I will add this in the next patch.

>
> > +
> > +properties:
> > +  enable-gpio:
>
> "gpios", so:
> enable-gpios

If this otg regulator only uses one GPIO Pin, do I still need to
change to "gpios"?
If so, I will refine it along with the regulator "enable-gpio" in MFD
dt-binding.

>
> > +maxItems: 1
> > +
> > +required:
> > +  - compatible
> > +  - interrupts
> > +  - interrupt-names
> > +  - io-channels
> > +
> > +additionalProperties: false
> > +
> > +...
>
>
> Best regards,
> Krzysztof

Best regards,
ChiaEn Wu

Re: [PATCH 1/2] agp/intel: Rename intel-gtt symbols

2022-06-17 Thread Tvrtko Ursulin




On 16/06/2022 23:49, Lucas De Marchi wrote:

Exporting the symbols like intel_gtt_* creates some confusion inside
i915 that has symbols named similarly. In an attempt to isolate
platforms needing intel-gtt.ko, commit 7a5c922377b4 ("drm/i915/gt: Split
intel-gtt functions by arch") moved way too much
inside gt/intel_gt_gmch.c, even the functions that don't callout to this
module. Rename the symbols to make the separation clear.

Signed-off-by: Lucas De Marchi 
---
  drivers/char/agp/intel-gtt.c| 58 -
  drivers/gpu/drm/i915/gt/intel_gt_gmch.c | 16 +++
  include/drm/intel-gtt.h | 24 +-
  3 files changed, 49 insertions(+), 49 deletions(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 79a1b65527c2..fe7e2105e766 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -744,7 +744,7 @@ static void i830_write_entry(dma_addr_t addr, unsigned int 
entry,
writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
  }
  
-bool intel_enable_gtt(void)

+bool intel_gmch_enable_gtt(void)
  {
u8 __iomem *reg;
  
@@ -787,7 +787,7 @@ bool intel_enable_gtt(void)
  
  	return true;

  }
-EXPORT_SYMBOL(intel_enable_gtt);
+EXPORT_SYMBOL(intel_gmch_enable_gtt);
  
  static int i830_setup(void)

  {
@@ -821,8 +821,8 @@ static int intel_fake_agp_free_gatt_table(struct 
agp_bridge_data *bridge)
  
  static int intel_fake_agp_configure(void)

  {
-   if (!intel_enable_gtt())
-   return -EIO;
+   if (!intel_gmch_enable_gtt())
+   return -EIO;
  
  	intel_private.clear_fake_agp = true;

agp_bridge->gart_bus_addr = intel_private.gma_bus_addr;
@@ -844,20 +844,20 @@ static bool i830_check_flags(unsigned int flags)
return false;
  }
  
-void intel_gtt_insert_page(dma_addr_t addr,

-  unsigned int pg,
-  unsigned int flags)
+void intel_gmch_gtt_insert_page(dma_addr_t addr,
+   unsigned int pg,
+   unsigned int flags)
  {
intel_private.driver->write_entry(addr, pg, flags);
readl(intel_private.gtt + pg);
if (intel_private.driver->chipset_flush)
intel_private.driver->chipset_flush();
  }
-EXPORT_SYMBOL(intel_gtt_insert_page);
+EXPORT_SYMBOL(intel_gmch_gtt_insert_page);
  
-void intel_gtt_insert_sg_entries(struct sg_table *st,

-unsigned int pg_start,
-unsigned int flags)
+void intel_gmch_gtt_insert_sg_entries(struct sg_table *st,
+ unsigned int pg_start,
+ unsigned int flags)
  {
struct scatterlist *sg;
unsigned int len, m;
@@ -879,13 +879,13 @@ void intel_gtt_insert_sg_entries(struct sg_table *st,
if (intel_private.driver->chipset_flush)
intel_private.driver->chipset_flush();
  }
-EXPORT_SYMBOL(intel_gtt_insert_sg_entries);
+EXPORT_SYMBOL(intel_gmch_gtt_insert_sg_entries);
  
  #if IS_ENABLED(CONFIG_AGP_INTEL)

-static void intel_gtt_insert_pages(unsigned int first_entry,
-  unsigned int num_entries,
-  struct page **pages,
-  unsigned int flags)
+static void intel_gmch_gtt_insert_pages(unsigned int first_entry,
+   unsigned int num_entries,
+   struct page **pages,
+   unsigned int flags)
  {
int i, j;
  
@@ -905,7 +905,7 @@ static int intel_fake_agp_insert_entries(struct agp_memory *mem,

if (intel_private.clear_fake_agp) {
int start = intel_private.stolen_size / PAGE_SIZE;
int end = intel_private.gtt_mappable_entries;
-   intel_gtt_clear_range(start, end - start);
+   intel_gmch_gtt_clear_range(start, end - start);
intel_private.clear_fake_agp = false;
}
  
@@ -934,12 +934,12 @@ static int intel_fake_agp_insert_entries(struct agp_memory *mem,

if (ret != 0)
return ret;
  
-		intel_gtt_insert_sg_entries(&st, pg_start, type);

+   intel_gmch_gtt_insert_sg_entries(&st, pg_start, type);
mem->sg_list = st.sgl;
mem->num_sg = st.nents;
} else
-   intel_gtt_insert_pages(pg_start, mem->page_count, mem->pages,
-  type);
+   intel_gmch_gtt_insert_pages(pg_start, mem->page_count, 
mem->pages,
+   type);
  
  out:

ret = 0;
@@ -949,7 +949,7 @@ static int intel_fake_agp_insert_entries(struct agp_memory 
*mem,
  }
  #endif
  
-void intel_gtt_clear_range(unsigned int first_entry, unsigned int num_entries)

+void intel_gmch_gtt_clear_range(unsigned int first_entry, unsig

Re: [PATCH 3/7] dt-bindings: display: mediatek: add bindings for MT8365 SoC





On 30/05/2022 22:14, Fabien Parent wrote:

Add MT8365 binding documentation for all the display components that are
compatible with the compatible string from other SoCs.

Signed-off-by: Fabien Parent 


Reviewed-by: Matthias Brugger 


---
  .../bindings/display/mediatek/mediatek,aal.yaml |  1 +
  .../display/mediatek/mediatek,ccorr.yaml|  1 +
  .../display/mediatek/mediatek,color.yaml|  1 +
  .../display/mediatek/mediatek,dither.yaml   |  1 +
  .../bindings/display/mediatek/mediatek,dsi.yaml | 17 +++--
  .../display/mediatek/mediatek,gamma.yaml|  1 +
  .../display/mediatek/mediatek,mutex.yaml|  1 +
  .../bindings/display/mediatek/mediatek,ovl.yaml |  1 +
  .../display/mediatek/mediatek,rdma.yaml |  1 +
  9 files changed, 19 insertions(+), 6 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index d4d585485e7b..d47bc72f09c0 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -33,6 +33,7 @@ properties:
- mediatek,mt8186-disp-aal
- mediatek,mt8192-disp-aal
- mediatek,mt8195-disp-aal
+  - mediatek,mt8365-disp-aal
- const: mediatek,mt8183-disp-aal
  
reg:

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 63fb02014a56..fc999e614718 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -32,6 +32,7 @@ properties:
- items:
- enum:
- mediatek,mt8186-disp-ccorr
+  - mediatek,mt8365-disp-ccorr
- const: mediatek,mt8183-disp-ccorr
  
reg:

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index d2f89ee7996f..9d081da433e8 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -39,6 +39,7 @@ properties:
- mediatek,mt8186-disp-color
- mediatek,mt8192-disp-color
- mediatek,mt8195-disp-color
+  - mediatek,mt8365-disp-color
- const: mediatek,mt8173-disp-color
reg:
  maxItems: 1
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 8ad8187c02d1..a7706cd65675 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -29,6 +29,7 @@ properties:
- mediatek,mt8186-disp-dither
- mediatek,mt8192-disp-dither
- mediatek,mt8195-disp-dither
+  - mediatek,mt8365-disp-dither
- const: mediatek,mt8183-disp-dither
  
reg:

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index fa5bdf28668a..d17ea215960c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -22,12 +22,17 @@ allOf:
  
  properties:

compatible:
-enum:
-  - mediatek,mt2701-dsi
-  - mediatek,mt7623-dsi
-  - mediatek,mt8167-dsi
-  - mediatek,mt8173-dsi
-  - mediatek,mt8183-dsi
+oneOf:
+  - enum:
+  - mediatek,mt2701-dsi
+  - mediatek,mt7623-dsi
+  - mediatek,mt8167-dsi
+  - mediatek,mt8173-dsi
+  - mediatek,mt8183-dsi
+  - items:
+  - enum:
+  - mediatek,mt8365-dsi
+  - const: mediatek,mt8183-dsi
  
reg:

  maxItems: 1
diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index a89ea0ea7542..f54859cfc97b 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -30,6 +30,7 @@ properties:
- mediatek,mt8186-disp-gamma
- mediatek,mt8192-disp-gamma
- mediatek,mt8195-disp-gamma
+  - mediatek,mt8365-disp-gamma
- const: mediatek,mt8183-disp-gamma
  
reg:

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml
index 3fdad71210b4..f4a12dfae77b 100644
--- a/Doc

Re: [PATCH 4/7] soc: mediatek: mutex: add MT8365 support





On 17/06/2022 07:50, CK Hu wrote:

Hi, Fabien:

On Mon, 2022-05-30 at 22:14 +0200, Fabien Parent wrote:

Add mutex support for MT8365 SoC.


Reviewed-by: CK Hu 



Applied thanks!



Signed-off-by: Fabien Parent 
---
  drivers/soc/mediatek/mtk-mutex.c | 40

  1 file changed, 40 insertions(+)

diff --git a/drivers/soc/mediatek/mtk-mutex.c
b/drivers/soc/mediatek/mtk-mutex.c
index 981d56967e7a..b8d5c4a62542 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -110,6 +110,20 @@
  #define MT8195_MUTEX_MOD_DISP_DP_INTF021
  #define MT8195_MUTEX_MOD_DISP_PWM027
  
+#define MT8365_MUTEX_MOD_DISP_OVL0		7

+#define MT8365_MUTEX_MOD_DISP_OVL0_2L  8
+#define MT8365_MUTEX_MOD_DISP_RDMA09
+#define MT8365_MUTEX_MOD_DISP_RDMA110
+#define MT8365_MUTEX_MOD_DISP_WDMA011
+#define MT8365_MUTEX_MOD_DISP_COLOR0   12
+#define MT8365_MUTEX_MOD_DISP_CCORR13
+#define MT8365_MUTEX_MOD_DISP_AAL  14
+#define MT8365_MUTEX_MOD_DISP_GAMMA15
+#define MT8365_MUTEX_MOD_DISP_DITHER   16
+#define MT8365_MUTEX_MOD_DISP_DSI0 17
+#define MT8365_MUTEX_MOD_DISP_PWM0 20
+#define MT8365_MUTEX_MOD_DISP_DPI0 22
+
  #define MT2712_MUTEX_MOD_DISP_PWM210
  #define MT2712_MUTEX_MOD_DISP_OVL011
  #define MT2712_MUTEX_MOD_DISP_OVL112
@@ -315,6 +329,22 @@ static const unsigned int
mt8195_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_DP_INTF0] = MT8195_MUTEX_MOD_DISP_DP_INTF0,
  };
  
+static const unsigned int mt8365_mutex_mod[DDP_COMPONENT_ID_MAX] = {

+   [DDP_COMPONENT_AAL0] = MT8365_MUTEX_MOD_DISP_AAL,
+   [DDP_COMPONENT_CCORR] = MT8365_MUTEX_MOD_DISP_CCORR,
+   [DDP_COMPONENT_COLOR0] = MT8365_MUTEX_MOD_DISP_COLOR0,
+   [DDP_COMPONENT_DITHER] = MT8365_MUTEX_MOD_DISP_DITHER,
+   [DDP_COMPONENT_DPI0] = MT8365_MUTEX_MOD_DISP_DPI0,
+   [DDP_COMPONENT_DSI0] = MT8365_MUTEX_MOD_DISP_DSI0,
+   [DDP_COMPONENT_GAMMA] = MT8365_MUTEX_MOD_DISP_GAMMA,
+   [DDP_COMPONENT_OVL0] = MT8365_MUTEX_MOD_DISP_OVL0,
+   [DDP_COMPONENT_OVL_2L0] = MT8365_MUTEX_MOD_DISP_OVL0_2L,
+   [DDP_COMPONENT_PWM0] = MT8365_MUTEX_MOD_DISP_PWM0,
+   [DDP_COMPONENT_RDMA0] = MT8365_MUTEX_MOD_DISP_RDMA0,
+   [DDP_COMPONENT_RDMA1] = MT8365_MUTEX_MOD_DISP_RDMA1,
+   [DDP_COMPONENT_WDMA0] = MT8365_MUTEX_MOD_DISP_WDMA0,
+};
+
  static const unsigned int mt2712_mutex_sof[DDP_MUTEX_SOF_MAX] = {
[MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
[MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
@@ -423,6 +453,14 @@ static const struct mtk_mutex_data
mt8195_mutex_driver_data = {
.mutex_sof_reg = MT8183_MUTEX0_SOF0,
  };
  
+static const struct mtk_mutex_data mt8365_mutex_driver_data = {

+   .mutex_mod = mt8365_mutex_mod,
+   .mutex_sof = mt8183_mutex_sof,
+   .mutex_mod_reg = MT8183_MUTEX0_MOD0,
+   .mutex_sof_reg = MT8183_MUTEX0_SOF0,
+   .no_clk = true,
+};
+
  struct mtk_mutex *mtk_mutex_get(struct device *dev)
  {
struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
@@ -665,6 +703,8 @@ static const struct of_device_id
mutex_driver_dt_match[] = {
  .data = &mt8192_mutex_driver_data},
{ .compatible = "mediatek,mt8195-disp-mutex",
  .data = &mt8195_mutex_driver_data},
+   { .compatible = "mediatek,mt8365-disp-mutex",
+ .data = &mt8365_mutex_driver_data},
{},
  };
  MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);

Re: [PATCH 5/7] soc: mediatek: mt8365-mmsys: add DPI/HDMI display path





On 17/06/2022 07:53, CK Hu wrote:

Hi, Fabien:

On Mon, 2022-05-30 at 22:14 +0200, Fabien Parent wrote:

Right now only the DSI path connections are described in the mt8365
mmsys driver. The external path will be DPI/HDMI. This commit adds
the connections for DPI/HDMI.


Reviewed-by: CK Hu 




Applied, thanks!



Signed-off-by: Fabien Parent 
---
  drivers/soc/mediatek/mt8365-mmsys.h | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/drivers/soc/mediatek/mt8365-mmsys.h
b/drivers/soc/mediatek/mt8365-mmsys.h
index 24129a6c25f8..7abaf048d91e 100644
--- a/drivers/soc/mediatek/mt8365-mmsys.h
+++ b/drivers/soc/mediatek/mt8365-mmsys.h
@@ -10,6 +10,9 @@
  #define MT8365_DISP_REG_CONFIG_DISP_RDMA0_RSZ0_SEL_IN 0xf60
  #define MT8365_DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0xf64
  #define MT8365_DISP_REG_CONFIG_DISP_DSI0_SEL_IN   0xf68
+#define MT8365_DISP_REG_CONFIG_DISP_RDMA1_SOUT_SEL 0xfd0
+#define MT8365_DISP_REG_CONFIG_DISP_DPI0_SEL_IN0xfd8
+#define MT8365_DISP_REG_CONFIG_DISP_LVDS_SYS_CFG_000xfdc
  
  #define MT8365_RDMA0_SOUT_COLOR0			0x1

  #define MT8365_DITHER_MOUT_EN_DSI00x1
@@ -18,6 +21,10 @@
  #define MT8365_RDMA0_RSZ0_SEL_IN_RDMA00x0
  #define MT8365_DISP_COLOR_SEL_IN_COLOR0   0x0
  #define MT8365_OVL0_MOUT_PATH0_SELBIT(0)
+#define MT8365_RDMA1_SOUT_DPI0 0x1
+#define MT8365_DPI0_SEL_IN_RDMA1   0x0
+#define MT8365_LVDS_SYS_CFG_00_SEL_LVDS_PXL_CLK0x1
+#define MT8365_DPI0_SEL_IN_RDMA1   0x0
  
  static const struct mtk_mmsys_routes mt8365_mmsys_routing_table[] =

{
{
@@ -55,6 +62,21 @@ static const struct mtk_mmsys_routes
mt8365_mmsys_routing_table[] = {
MT8365_DISP_REG_CONFIG_DISP_RDMA0_RSZ0_SEL_IN,
MT8365_RDMA0_RSZ0_SEL_IN_RDMA0,
MT8365_RDMA0_RSZ0_SEL_IN_RDMA0
},
+   {
+   DDP_COMPONENT_RDMA1, DDP_COMPONENT_DPI0,
+   MT8365_DISP_REG_CONFIG_DISP_LVDS_SYS_CFG_00,
+   MT8365_LVDS_SYS_CFG_00_SEL_LVDS_PXL_CLK,
MT8365_LVDS_SYS_CFG_00_SEL_LVDS_PXL_CLK
+   },
+   {
+   DDP_COMPONENT_RDMA1, DDP_COMPONENT_DPI0,
+   MT8365_DISP_REG_CONFIG_DISP_DPI0_SEL_IN,
+   MT8365_DPI0_SEL_IN_RDMA1, MT8365_DPI0_SEL_IN_RDMA1
+   },
+   {
+   DDP_COMPONENT_RDMA1, DDP_COMPONENT_DPI0,
+   MT8365_DISP_REG_CONFIG_DISP_RDMA1_SOUT_SEL,
+   MT8365_RDMA1_SOUT_DPI0, MT8365_RDMA1_SOUT_DPI0
+   },
  };
  
  #endif /* __SOC_MEDIATEK_MT8365_MMSYS_H */

Re: [PATCH v2 4/4] drm/bridge: anx7625: Use DPI bus type

2022-06-17 Thread Chen-Yu Tsai

Hi,

On Mon, May 23, 2022 at 4:37 PM Robert Foss  wrote:
>
> On Mon, 23 May 2022 at 09:18, Chen-Yu Tsai  wrote:
> >
> > On Mon, May 23, 2022 at 11:13 AM Xin Ji  wrote:
> > >
> > > On Sat, May 21, 2022 at 06:28:42PM +0200, Daniel Vetter wrote:
> > > > On Sat, 21 May 2022 at 18:07, Daniel Vetter  wrote:
> > > > >
> > > > > On Tue, 17 May 2022 at 18:09, Robert Foss  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, 25 Apr 2022 at 11:14, Xin Ji  wrote:
> > > > > > >
> > > > > > > On Mon, Apr 25, 2022 at 04:24:50PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > On Fri, Apr 22, 2022 at 10:13 PM Robert Foss 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Fri, 22 Apr 2022 at 16:01, Robert Foss 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, 22 Apr 2022 at 10:49, Xin Ji 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > As V4L2_FWNODE_BUS_TYPE_PARALLEL not properly descript 
> > > > > > > > > > > for DPI
> > > > > > > > > > > interface, this patch use new defined 
> > > > > > > > > > > V4L2_FWNODE_BUS_TYPE_DPI for it.
> > > > > > > > > > >
> > > > > > > > > > > Fixes: fd0310b6fe7d ("drm/bridge: anx7625: add MIPI DPI 
> > > > > > > > > > > input feature")
> > > > > > > > > > > Signed-off-by: Xin Ji 
> > > > > > > > > > > ---
> > > > > > > > > > >  drivers/gpu/drm/bridge/analogix/anx7625.c | 8 
> > > > > > > > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
> > > > > > > > > > > b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > > > > > > > > > index 376da01243a3..71df977e8f53 100644
> > > > > > > > > > > --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > > > > > > > > > +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> > > > > > > > > > > @@ -1623,14 +1623,14 @@ static int 
> > > > > > > > > > > anx7625_parse_dt(struct device *dev,
> > > > > > > > > > >
> > > > > > > > > > > anx7625_get_swing_setting(dev, pdata);
> > > > > > > > > > >
> > > > > > > > > > > -   pdata->is_dpi = 1; /* default dpi mode */
> > > > > > > > > > > +   pdata->is_dpi = 0; /* default dsi mode */
> > > > > > > > > > > pdata->mipi_host_node = 
> > > > > > > > > > > of_graph_get_remote_node(np, 0, 0);
> > > > > > > > > > > if (!pdata->mipi_host_node) {
> > > > > > > > > > > DRM_DEV_ERROR(dev, "fail to get internal 
> > > > > > > > > > > panel.\n");
> > > > > > > > > > > return -ENODEV;
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > -   bus_type = V4L2_FWNODE_BUS_TYPE_PARALLEL;
> > > > > > > > > > > +   bus_type = 0;
> > > > > > > > > > > mipi_lanes = MAX_LANES_SUPPORT;
> > > > > > > > > > > ep0 = of_graph_get_endpoint_by_regs(np, 0, 0);
> > > > > > > > > > > if (ep0) {
> > > > > > > > > > > @@ -1640,8 +1640,8 @@ static int anx7625_parse_dt(struct 
> > > > > > > > > > > device *dev,
> > > > > > > > > > > mipi_lanes = 
> > > > > > > > > > > of_property_count_u32_elems(ep0, "data-lanes");
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > -   if (bus_type == V4L2_FWNODE_BUS_TYPE_PARALLEL) /* 
> > > > > > > > > > > bus type is Parallel(DSI) */
> > > > > > > > > > > -   pdata->is_dpi = 0;
> > > > > > > > > > > +   if (bus_type == V4L2_FWNODE_BUS_TYPE_DPI) /* bus 
> > > > > > > > > > > type is DPI */
> > > > > > > > > > > +   pdata->is_dpi = 1;
> > > > > > > > > > >
> > > > > > > > > > > pdata->mipi_lanes = mipi_lanes;
> > > > > > > > > > > if (pdata->mipi_lanes > MAX_LANES_SUPPORT || 
> > > > > > > > > > > pdata->mipi_lanes <= 0)
> > > > > > > > > >
> > > > > > > > > > Reviewed-by: Robert Foss 
> > > > > > > > >
> > > > > > > > > Acked-by: Robert Foss 
> > > > > > > >
> > > > > > > > Tested-by: Chen-Yu Tsai 
> > > > > > > >
> > > > > > > > Confirmed this fixes the display on Juniper (Acer Chromebook 
> > > > > > > > Spin 311) on
> > > > > > > > mainline (next-20220422).
> > > > > > > >
> > > > > > > > Xin, in the future, please send the whole series to all 
> > > > > > > > recipients of
> > > > > > > > all patches listed by get_maintainers.pl, not just the 
> > > > > > > > recipients of
> > > > > > > > each patch. In the case of this series, they should have been 
> > > > > > > > sent
> > > > > > > > to all of the mailing lists (media, devicetree, dri-devel) so 
> > > > > > > > that
> > > > > > > > everyone has the same, full view of the patches.
> > > > > > > Hi ChenYu, OK, I'll send to all media, devicetree, dri-devel next 
> > > > > > > time.
> > > > > > > Thanks,
> > > > > > > Xin
> > > > > > > >
> > > > > > > > ChenYu
> > > > > >
> > > > > > Applied 3/4 + 4/4 to drm-misc-next.
> > > > >
> > > > > This patch doesn't even compile. Can you pls fix this up asap? Also
> > > > > pls compile-test before pushing ...
> > > >
> > > > Marek says the prerequisite landed thr

[PATCH 0/3] drm: Test for primary plane in new drm_atomic_helper_check_crtc_state()

Provide drm_atomic_helper_check_crtc_state() for validating a CRTC
state against common constraints. As many CRTC need a primary plane
to work correctly, add this as the first test.

The simple-KMS helpers already contain related code. Convert it
to the new helper. Also add this test to ast.

The simple-kms changes were tested with simpledrm. The ast changes
were tested in AST2300 hardware.

Thomas Zimmermann (3):
  drm/atomic-helper: Add helper drm_atomic_helper_check_crtc_state()
  drm/simple-kms: Use drm_atomic_helper_check_crtc_state()
  drm/ast: Enable primary plane with CRTC

 drivers/gpu/drm/ast/ast_mode.c  | 13 --
 drivers/gpu/drm/drm_atomic_helper.c | 55 +
 drivers/gpu/drm/drm_simple_kms_helper.c | 14 +++
 include/drm/drm_atomic_helper.h |  2 +
 4 files changed, 72 insertions(+), 12 deletions(-)


base-commit: 822a8442835012ce405080cb40f6317ef1e854ac
-- 
2.36.1

[PATCH 3/3] drm/ast: Enable primary plane with CRTC

As the CRTC requires a primary plane for display, ensure that the
primary plane is enabled with the CRTC.

Use drm_atomic_helper_check_crtc_state(). Add all affected planes
to the atomic state so that their state will be checked as well.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_mode.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index db2010a55674..e992e07a26f9 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1094,15 +1094,19 @@ ast_crtc_helper_mode_valid(struct drm_crtc *crtc, const 
struct drm_display_mode
 static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc,
struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
- crtc);
+   struct drm_crtc_state *crtc_state = 
drm_atomic_get_new_crtc_state(state, crtc);
struct drm_device *dev = crtc->dev;
struct ast_crtc_state *ast_state;
const struct drm_format_info *format;
bool succ;
+   int ret;
+
+   ret = drm_atomic_helper_check_crtc_state(crtc_state, false);
+   if (ret)
+   return ret;
 
if (!crtc_state->enable)
-   return 0; /* no mode checks if CRTC is being disabled */
+   goto out;
 
ast_state = to_ast_crtc_state(crtc_state);
 
@@ -1116,7 +1120,8 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc 
*crtc,
if (!succ)
return -EINVAL;
 
-   return 0;
+out:
+   return drm_atomic_add_affected_planes(state, crtc);
 }
 
 static void ast_crtc_helper_atomic_begin(struct drm_crtc *crtc, struct 
drm_atomic_state *state)
-- 
2.36.1

[PATCH 2/3] drm/simple-kms: Use drm_atomic_helper_check_crtc_state()

Simple-KMS helpers guarantee that the CRTC and plane enable
flags are synchronized. Implement this with atomic helpers
drm_atomic_helper_check_crtc_state() on the CRTC side, and
drm_atomic_helper_check_plane_state() on the plane side.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 72989ed1baba..36633590ebf3 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -100,14 +100,12 @@ drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
 static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
 struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *crtc_state = drm_atomic_get_new_crtc_state(state,
- crtc);
-   bool has_primary = crtc_state->plane_mask &
-  drm_plane_mask(crtc->primary);
+   struct drm_crtc_state *crtc_state = 
drm_atomic_get_new_crtc_state(state, crtc);
+   int ret;
 
-   /* We always want to have an active plane with an active CRTC */
-   if (has_primary != crtc_state->enable)
-   return -EINVAL;
+   ret = drm_atomic_helper_check_crtc_state(crtc_state, false);
+   if (ret)
+   return ret;
 
return drm_atomic_add_affected_planes(state, crtc);
 }
@@ -227,7 +225,7 @@ static int drm_simple_kms_plane_atomic_check(struct 
drm_plane *plane,
ret = drm_atomic_helper_check_plane_state(plane_state, crtc_state,
  DRM_PLANE_HELPER_NO_SCALING,
  DRM_PLANE_HELPER_NO_SCALING,
- false, true);
+ false, false);
if (ret)
return ret;
 
-- 
2.36.1

[PATCH 1/3] drm/atomic-helper: Add helper drm_atomic_helper_check_crtc_state()

Add drm_atomic_helper_check_crtc_state(), which contains tests common
to many CRTCs. The first added test verifies that an enabled CRTC has
at least one enabled primary plane.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_atomic_helper.c | 55 +
 include/drm/drm_atomic_helper.h |  2 ++
 2 files changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 987e4b212e9f..329d8a3c3d65 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -875,6 +875,61 @@ int drm_atomic_helper_check_plane_state(struct 
drm_plane_state *plane_state,
 }
 EXPORT_SYMBOL(drm_atomic_helper_check_plane_state);
 
+/**
+ * drm_atomic_helper_check_crtc_state() - Check CRTC state for validity
+ * @crtc_state: CRTC state to check
+ * @can_disable_primary_planes: can the CRTC be enabled without a primary 
plane?
+ *
+ * Checks that a desired CRTC update is valid. Drivers that provide
+ * their own CRTC handling rather than helper-provided implementations may
+ * still wish to call this function to avoid duplication of error checking
+ * code.
+ *
+ * Note that @can_disable_primary_planes only tests if the CRTC can be
+ * enabled without a primary plane. To test if a primary plane can be updated
+ * without a CRTC, use drm_atomic_helper_check_plane_state() in the plane's
+ * atomic check.
+ *
+ * RETURNS:
+ * Zero if update appears valid, error code on failure
+ */
+int drm_atomic_helper_check_crtc_state(struct drm_crtc_state *crtc_state,
+  bool can_disable_primary_planes)
+{
+   struct drm_device *dev = crtc_state->crtc->dev;
+   struct drm_atomic_state *state = crtc_state->state;
+
+   if (!crtc_state->enable)
+   return 0;
+
+   /* needs at least one primary plane to be enabled */
+   if (!can_disable_primary_planes) {
+   bool has_primary_plane = false;
+   struct drm_plane *plane;
+
+   drm_for_each_plane_mask(plane, dev, crtc_state->plane_mask) {
+   struct drm_plane_state *plane_state;
+
+   if (plane->type != DRM_PLANE_TYPE_PRIMARY)
+   continue;
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state))
+   return PTR_ERR(plane_state);
+   if (plane_state->fb && plane_state->crtc) {
+   has_primary_plane = true;
+   break;
+   }
+   }
+   if (!has_primary_plane) {
+   drm_dbg_kms(dev, "Cannot enable CRTC without a primary 
plane.\n");
+   return -EINVAL;
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_atomic_helper_check_crtc_state);
+
 /**
  * drm_atomic_helper_check_planes - validate state object for planes changes
  * @dev: DRM device
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 4045e2507e11..2a0b17842402 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -46,6 +46,8 @@ int drm_atomic_helper_check_plane_state(struct 
drm_plane_state *plane_state,
int max_scale,
bool can_position,
bool can_update_disabled);
+int drm_atomic_helper_check_crtc_state(struct drm_crtc_state *crtc_state,
+  bool can_disable_primary_plane);
 int drm_atomic_helper_check_planes(struct drm_device *dev,
   struct drm_atomic_state *state);
 int drm_atomic_helper_check(struct drm_device *dev,
-- 
2.36.1

Re: [PATCH 2/2] drm/i915/gt: Re-do the intel-gtt split

2022-06-17 Thread Tvrtko Ursulin




On 16/06/2022 23:49, Lucas De Marchi wrote:

Re-do what was attempted in commit 7a5c922377b4 ("drm/i915/gt: Split
intel-gtt functions by arch"). The goal of that commit was to split the
handlers for older hardware that depend on intel-gtt.ko so i915 can
be built for non-x86 archs, after some more patches. Other archs do not
need intel-gtt.ko.

Main issue with the previous approach: it moved all the hooks, including
the gen8, which is used by all platforms gen8 and newer.  Re-do the
split moving only the handlers for gen < 6, which are the only ones
calling out to the separate module.


Indeed way too much.. where I was looking at..


Signed-off-by: Lucas De Marchi 
---
  drivers/gpu/drm/i915/Makefile |   2 +-
  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 559 +-
  drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 132 +
  drivers/gpu/drm/i915/gt/intel_ggtt_gmch.h |  27 +
  drivers/gpu/drm/i915/gt/intel_gt.c|   5 +-
  drivers/gpu/drm/i915/gt/intel_gt.h|   9 -
  drivers/gpu/drm/i915/gt/intel_gt_gmch.c   | 654 --
  drivers/gpu/drm/i915/gt/intel_gt_gmch.h   |  46 --
  drivers/gpu/drm/i915/gt/intel_gtt.h   |  12 +-
  9 files changed, 713 insertions(+), 733 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c
  create mode 100644 drivers/gpu/drm/i915/gt/intel_ggtt_gmch.h
  delete mode 100644 drivers/gpu/drm/i915/gt/intel_gt_gmch.c
  delete mode 100644 drivers/gpu/drm/i915/gt/intel_gt_gmch.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d2b18f03a33c..4166cd76997e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -129,7 +129,7 @@ gt-y += \
gt/shmem_utils.o \
gt/sysfs_engines.o
  # x86 intel-gtt module support
-gt-$(CONFIG_X86) += gt/intel_gt_gmch.o
+gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
  # autogenerated null render state
  gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index e6b2eb122ad7..a83d6858b766 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -3,16 +3,18 @@
   * Copyright © 2020 Intel Corporation
   */
  
-#include 

  #include 
  #include 
+#include 
+#include 
  
  #include 

+#include 
  
  #include "gem/i915_gem_lmem.h"
  
+#include "intel_ggtt_gmch.h"

  #include "intel_gt.h"
-#include "intel_gt_gmch.h"
  #include "intel_gt_regs.h"
  #include "i915_drv.h"
  #include "i915_scatterlist.h"
@@ -181,7 +183,7 @@ void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
spin_unlock_irq(&uncore->lock);
  }
  
-void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)

+static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
  {
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
  
@@ -218,11 +220,232 @@ u64 gen8_ggtt_pte_encode(dma_addr_t addr,

return pte;
  }
  
+static void gen8_set_pte(void __iomem *addr, gen8_pte_t pte)

+{
+   writeq(pte, addr);
+}
+
+static void gen8_ggtt_insert_page(struct i915_address_space *vm,
+ dma_addr_t addr,
+ u64 offset,
+ enum i915_cache_level level,
+ u32 flags)
+{
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
+   gen8_pte_t __iomem *pte =
+   (gen8_pte_t __iomem *)ggtt->gsm + offset / I915_GTT_PAGE_SIZE;
+
+   gen8_set_pte(pte, gen8_ggtt_pte_encode(addr, level, flags));
+
+   ggtt->invalidate(ggtt);
+}
+
+static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
+struct i915_vma_resource *vma_res,
+enum i915_cache_level level,
+u32 flags)
+{
+   const gen8_pte_t pte_encode = gen8_ggtt_pte_encode(0, level, flags);
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
+   gen8_pte_t __iomem *gte;
+   gen8_pte_t __iomem *end;
+   struct sgt_iter iter;
+   dma_addr_t addr;
+
+   /*
+* Note that we ignore PTE_READ_ONLY here. The caller must be careful
+* not to allow the user to override access to a read only page.
+*/
+
+   gte = (gen8_pte_t __iomem *)ggtt->gsm;
+   gte += vma_res->start / I915_GTT_PAGE_SIZE;
+   end = gte + vma_res->node_size / I915_GTT_PAGE_SIZE;
+
+   for_each_sgt_daddr(addr, iter, vma_res->bi.pages)
+   gen8_set_pte(gte++, pte_encode | addr);
+   GEM_BUG_ON(gte > end);
+
+   /* Fill the allocated but "unused" space beyond the end of the buffer */
+   while (gte < end)
+   gen8_set_pte(gte++, vm->scratch[0]->encode);
+
+   /*
+* We want to flush the TLBs only after we're certain all the PTE
+* updates have finished.
+*/
+   ggtt->invalidate(ggtt);
+}
+
+static void gen6_ggtt_insert_page(struct i915_address_space *vm,
+

Re: [PATCH v2 05/15] dt-bindings: backlight: Add Mediatek MT6370 backlight

Hi Krzysztof,

Thanks for your helpful feedback, I have some questions want to
confirm with you below.

Krzysztof Kozlowski  於 2022年6月17日 週五 清晨5:13寫道：
>
> On 13/06/2022 04:11, ChiaEn Wu wrote:
> > From: ChiYuan Huang 
> >
> > Add mt6370 backlight binding documentation.
> >
> > Signed-off-by: ChiYuan Huang 
> > ---
> >  .../backlight/mediatek,mt6370-backlight.yaml  | 107 ++
> >  1 file changed, 107 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
> >  
> > b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
> > new file mode 100644
> > index ..25a05e607e83
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/leds/backlight/mediatek,mt6370-backlight.yaml
> > @@ -0,0 +1,107 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: 
> > http://devicetree.org/schemas/leds/backlight/mediatek,mt6370-backlight.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mediatek MT6370 Backlight
> > +
> > +maintainers:
> > +  - ChiaEn Wu 
> > +
> > +description: |
> > +  This module is part of the MT6370 MFD device.
> > +  The MT6370 Backlight WLED driver supports up to a 29V output voltage for
> > +  4 channels of 8 series WLEDs. Each channel supports up to 30mA of current
> > +  capability with 2048 current steps (11 bits) in exponential or linear
> > +  mapping curves.
> > +
> > +allOf:
> > +  - $ref: common.yaml#
> > +
> > +properties:
> > +  compatible:
> > +const: mediatek,mt6370-backlight
> > +
> > +  default-brightness:
> > +minimum: 0
> > +maximum: 2048
> > +
> > +  max-brightness:
> > +minimum: 0
> > +maximum: 2048
> > +
> > +  enable-gpios:
> > +description: External backlight 'enable' pin
> > +maxItems: 1
> > +
> > +  mediatek,bled-pwm-enable:
> > +description: |
> > +  Enable external PWM input for backlight dimming
> > +type: boolean
> > +
> > +  mediatek,bled-pwm-hys-enable:
> > +description: |
> > +  Enable the backlight input-hysteresis for PWM mode
> > +type: boolean
> > +
> > +  mediatek,bled-pwm-hys-input-bit:
> > +$ref: /schemas/types.yaml#/definitions/uint8
> > +enum: [0, 1, 2, 3]
> > +description: |
> > +  The selection of the upper and lower bounds threshold of backlight
> > +  PWM resolution. If we choose selection 3 (6 bits), the variation of 
> > PWM
> > +  resolution needs over than 64 steps (2^6).
> > +  value mapping:
> > +- 0: 1
> > +- 1: 2
> > +- 2: 4
> > +- 3: 6
>
> Nope, I said last time:
> "In any case you cannot have values mapping"
>
> Please use proper real world value, not some register bits. The property
> name also needs fixing.

I so apologized for misunderstanding your meaning...
I try to modify it like below.

mediatek,bled-pwm-hys-input-threshold-steps:
  $ref: /schemas/types.yaml#/definitions/uint8
  enum: [1, 4, 16, 64]
  description: |
The selection of the upper and lower bounds threshold of backlight
PWM resolution. If we choose selection 64, the variation of PWM
resolution needs over 64 steps.

If these changes meet your expectations, I will try to modify
"bled-ovp-microvolt" and "bled-ocp-microamp" in the same way.
Thank you so much.

>
> > +
> > +  mediatek,bled-ovp-shutdown:
> > +description: |
> > +  Enable the backlight shutdown when OVP level triggered
> > +type: boolean
> > +
> > +  mediatek,bled-ovp-microvolt:
> > +enum: [0, 1, 2, 3]
> > +description: |
> > +  Backlight OVP level selection.
> > +  value mapping:
> > +- 0: 1700
> > +- 1: 2100
> > +- 2: 2500
> > +- 3: 2900
>
> No. Please test your bindings.
>
> microvolt cannot be 1 mV. It's 2100, not 1. No value mappings.
>
> > +
> > +  mediatek,bled-ocp-shutdown:
> > +description: |
> > +  Enable the backlight shutdown when OCP level triggerred.
> > +type: boolean
> > +
> > +  mediatek,bled-ocp-microamp:
> > +enum: [0, 1, 2, 3]
> > +description: |
> > +  Backlight OC level selection.
> > +  value mapping:
> > +- 0: 90
> > +- 1: 120
> > +- 2: 150
> > +- 3: 180
>
> Nope.
>
> > +
> > +  mediatek,bled-channel-use:
> > +$ref: /schemas/types.yaml#/definitions/uint8
> > +description: |
> > +  Backlight LED channel to be used.
> > +  Each bit mapping to:
> > +- 0: CH4
> > +- 1: CH3
> > +- 2: CH2
> > +- 3: CH1
> > +minimum: 1
> > +maximum: 15
> > +
> > +required:
> > +  - compatible
> > +  - mediatek,bled-channel-use
> > +
> > +additionalProperties: false
>
>
> Best regards,
> Krzysztof

Best regards,
ChiaEn Wu

[PATCH 0/3] drm/msm/hdmi: turn MSM8996 HDMI PHY into OF clock provider

On MSM8996 the HDMI PHY is the QMP PHY, it provides an HDMI PLL clock
used by the MMCC. Add support for providing this clock to the OF
framework by registerding the clock provider and adding #clock-cells
property to the DT node.

Dmitry Baryshkov (3):
  dt-bindings: phy: qcom,hdmi-phy-qmp: add clock-cells
  drm/msm/hdmi: make hdmi_phy_8996 OF clk provider
  arm64: dts: qcom: msm8996: add #clock-cells to the HDMI PHY node

 .../bindings/phy/qcom,hdmi-phy-qmp.yaml   |  4 
 arch/arm64/boot/dts/qcom/msm8996.dtsi |  2 ++
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c  | 15 ++-
 3 files changed, 16 insertions(+), 5 deletions(-)

-- 
2.35.1

[PATCH 1/3] dt-bindings: phy: qcom,hdmi-phy-qmp: add clock-cells

As the QMP HDMI PHY is a clock provider, add constant #clock-cells
property. For the compatibility with older DTs the property is not
marked as required.

Signed-off-by: Dmitry Baryshkov 
---
 Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml 
b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
index eea2e02678ed..1ada0d9857c0 100644
--- a/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,hdmi-phy-qmp.yaml
@@ -44,6 +44,9 @@ properties:
   vddio-supply:
 description: phandle to VDD I/O supply regulator
 
+  '#clock-cells':
+const: 0
+
   '#phy-cells':
 const: 0
 
@@ -78,6 +81,7 @@ examples:
<&gcc 214>;
   clock-names = "iface",
 "ref";
+  #clock-cells = <0>;
   #phy-cells = <0>;
 
   vddio-supply = <&vreg_l12a_1p8>;
-- 
2.35.1

[PATCH 2/3] drm/msm/hdmi: make hdmi_phy_8996 OF clk provider

On MSM8996 the HDMI PHY provides the PLL clock to the MMCC. As we are
preparing to convert the MSM8996 to use DT clocks properties (rather
than global clock names), register the OF clock provider.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c 
b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
index b06d9d25a189..cfb83e9dd810 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c
@@ -707,8 +707,7 @@ int msm_hdmi_pll_8996_init(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
struct hdmi_pll_8996 *pll;
-   struct clk *clk;
-   int i;
+   int i, ret;
 
pll = devm_kzalloc(dev, sizeof(*pll), GFP_KERNEL);
if (!pll)
@@ -735,10 +734,16 @@ int msm_hdmi_pll_8996_init(struct platform_device *pdev)
}
pll->clk_hw.init = &pll_init;
 
-   clk = devm_clk_register(dev, &pll->clk_hw);
-   if (IS_ERR(clk)) {
+   ret = devm_clk_hw_register(dev, &pll->clk_hw);
+   if (ret) {
DRM_DEV_ERROR(dev, "failed to register pll clock\n");
-   return -EINVAL;
+   return ret;
+   }
+
+   ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, 
&pll->clk_hw);
+   if (ret) {
+   DRM_DEV_ERROR(dev, "%s: failed to register clk provider: %d\n", 
__func__, ret);
+   return ret;
}
 
return 0;
-- 
2.35.1

[PATCH 3/3] arm64: dts: qcom: msm8996: add #clock-cells to the HDMI PHY node

Add #clock-cells property to the HDMI PHY device node to let other nodes
resolve the hdmipll clock.

Signed-off-by: Dmitry Baryshkov 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 9932186f7ceb..f94f10947f26 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -964,6 +964,8 @@ hdmi_phy: hdmi-phy@9a0600 {
clock-names = "iface",
  "ref";
 
+   #clock-cells = <0>;
+
status = "disabled";
};
};
-- 
2.35.1

Re: [PATCH v2 06/15] dt-bindings: mfd: Add Mediatek MT6370

Hi Rob,

Rob Herring  於 2022年6月13日 週一 晚上9:33寫道：
>
> On Mon, 13 Jun 2022 19:11:37 +0800, ChiaEn Wu wrote:
> > From: ChiYuan Huang 
> >
> > Add Mediatek MT6370 binding documentation.
> >
> > Signed-off-by: ChiYuan Huang 
> > ---
> >  .../bindings/mfd/mediatek,mt6370.yaml | 279 ++
> >  .../dt-bindings/iio/adc/mediatek,mt6370_adc.h |  18 ++
> >  2 files changed, 297 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> >  create mode 100644 include/dt-bindings/iio/adc/mediatek,mt6370_adc.h
> >
>
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> ./Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml: Unable to find 
> schema file matching $id: 
> http://devicetree.org/schemas/leds/backlight/mediatek,mt6370-backlight.yaml
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
>  pmic@34: backlight: False schema does not allow {'compatible': 
> ['mediatek,mt6370-backlight'], 'mediatek,bled-channel-use': b'\x0f'}
> From schema: 
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
>  pmic@34: charger: False schema does not allow {'compatible': 
> ['mediatek,mt6370-charger'], 'interrupts': [[48], [68], [6]], 
> 'interrupt-names': ['attach_i', 'uvp_d_evt', 'mivr'], 'io-channels': [[1, 
> 5]], 'usb-otg-vbus-regulator': {'regulator-name': ['mt6370-usb-otg-vbus'], 
> 'regulator-min-microvolt': [[435]], 'regulator-max-microvolt': 
> [[580]], 'regulator-min-microamp': [[50]], 'regulator-max-microamp': 
> [[300]], 'phandle': [[2]]}}
> From schema: 
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
>  pmic@34: tcpc: False schema does not allow {'compatible': 
> ['mediatek,mt6370-tcpc'], 'interrupts-extended': [[4294967295, 4, 8]], 
> 'connector': {'compatible': ['usb-c-connector'], 'label': ['USB-C'], 
> 'vbus-supply': [[2]], 'data-role': ['dual'], 'power-role': ['dual'], 
> 'try-power-role': ['sink'], 'source-pdos': [[570527844]], 'sink-pdos': 
> [[570527944]], 'op-sink-microwatt': [[1000]], 'ports': {'#address-cells': 
> [[1]], '#size-cells': [[0]], 'port@0': {'reg': [[0]], 'endpoint': 
> {'remote-endpoint': [[4294967295]]}}, 'port@1': {'reg': [[1]], 'endpoint': 
> {'remote-endpoint': [[4294967295]]}}, 'port@2': {'reg': [[2]], 'endpoint': 
> {'remote-endpoint': [[4294967295]]}
> From schema: 
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
>  pmic@34: indicator: False schema does not allow {'compatible': 
> ['mediatek,mt6370-indicator'], '#address-cells': [[1]], '#size-cells': [[0]], 
> 'multi-led@0': {'reg': [[0]], 'function': ['indicator'], 'color': [[9]], 
> 'led-max-microamp': [[24000]], '#address-cells': [[1]], '#size-cells': [[0]], 
> 'led@0': {'reg': [[0]], 'color': [[1]]}, 'led@1': {'reg': [[1]], 'color': 
> [[2]]}, 'led@2': {'reg': [[2]], 'color': [[3]]}}, 'led@3': {'reg': [[3]], 
> 'function': ['indicator'], 'color': [[0]], 'led-max-microamp': [[6000]]}}
> From schema: 
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
>  pmic@34: flashlight: False schema does not allow {'compatible': 
> ['mediatek,mt6370-flashlight'], '#address-cells': [[1]], '#size-cells': 
> [[0]], 'led@0': {'reg': [[0]], 'led-sources': [[0]], 'function': ['flash'], 
> 'color': [[0]], 'function-enumerator': [[1]], 'led-max-microamp': [[20]], 
> 'flash-max-microamp': [[50]], 'flash-max-timeout-us': [[1248000]]}, 
> 'led@1': {'reg': [[1]], 'led-sources': [[1]], 'function': ['flash'], 'color': 
> [[0]], 'function-enumerator': [[2]], 'led-max-microamp': [[20]], 
> 'flash-max-microamp': [[50]], 'flash-max-timeout-us': [[1248000]]}}
> From schema: 
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:
>  backlight: mediatek,bled-channel-use: b'\x0f' is not of type 'object', 
> 'array', 'boolean', 'null'
> From schema: 
> /usr/local/lib/python3.10/dist-packages/dtschema/schemas/dt-core.yaml
> Documentation/devicetree/bindings/mfd/mediatek,mt6370.example.dtb:0:0: 
> /example-0/i2c/pmic@34/backlight: failed to match any schema with compatible: 
> ['mediatek,mt6370-bac

Re: [PATCH v2 06/15] dt-bindings: mfd: Add Mediatek MT6370

Hi Krzysztof,

Krzysztof Kozlowski  於 2022年6月17日 週五 清晨5:15寫道：
>
> On 13/06/2022 04:11, ChiaEn Wu wrote:
> > From: ChiYuan Huang 
> >
> > Add Mediatek MT6370 binding documentation.
> >
> > Signed-off-by: ChiYuan Huang 
> > ---
> >  .../bindings/mfd/mediatek,mt6370.yaml | 279 ++
> >  .../dt-bindings/iio/adc/mediatek,mt6370_adc.h |  18 ++
> >  2 files changed, 297 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> >  create mode 100644 include/dt-bindings/iio/adc/mediatek,mt6370_adc.h
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml 
> > b/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> > new file mode 100644
> > index ..6c2639e81e50
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6370.yaml
> > @@ -0,0 +1,279 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mfd/mediatek,mt6370.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mediatek MT6370 SubPMIC
> > +
> > +maintainers:
> > +  - ChiYuan Huang 
> > +
> > +description: |
> > +  MT6370 is a highly-integrated smart power management IC, which includes a
> > +  single cell Li-Ion/Li-Polymer switching battery charger, a USB Type-C &
> > +  Power Delivery (PD) controller, dual flash LED current sources, a RGB LED
> > +  driver, a backlight WLED driver, a display bias driver and a general LDO 
> > for
> > +  portable devices.
> > +
> > +properties:
> > +  compatible:
> > +const: mediatek,mt6370
> > +
> > +  reg:
> > +maxItems: 1
> > +
> > +  wakeup-source: true
> > +
> > +  interrupts:
> > +maxItems: 1
> > +
> > +  interrupt-controller: true
> > +
> > +  '#interrupt-cells':
> > +const: 1
> > +
> > +  adc:
> > +type: object
> > +description: |
> > +  Provides 9 channels for system monitoring, including vbusdiv5, 
> > vbusdiv2,
> > +  vbat, vsys, chg_vddp, ts_bat, ibus, ibat, and temp_jc.
> > +
> > +properties:
> > +  compatible:
> > +const: mediatek,mt6370-adc
> > +
> > +  "#io-channel-cells":
> > +const: 1
> > +
> > +required:
> > +  - compatible
> > +  - '#io-channel-cells'
>
> Decide in your entire patchset whether you use ' or ". Don't mix.

Thanks for your comments.
We apologize for doing these mistakes...
We will use the same symbol in the entire patchset and check again
before the next submission.

>
> Since you did not test your bindings, I am not reviewing it. First, test
> them. No need for me to do the job of a automated tool, right?
>
> Best regards,
> Krzysztof

Best regards,
ChiaEn Wu

Re: radeon driver warning


Hi John,

well, this warning is intentional.

The key point is that your random config results in a very suboptimal 
situation where the graphics driver only barely work.


And radeon is pointing that out with this warning. That is totally 
expected behavior.


Regards,
Christian.

Am 17.06.22 um 12:57 schrieb John Garry:

Hi guys,

This warning in the radeon driver breaks my randconfig build on 
v5.19-rc2:


drivers/gpu/drm/radeon/radeon_object.c:186:2: error: #warning Please 
enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to 
write-combining 
[;;https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonl&data=05%7C01%7Cchristian.koenig%40amd.com%7C430e22f895ec4822fe5e08da50503030%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637910602602101203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vT%2BWgL83xuAOqv44oVU3J4ypTDzC9f%2FNslYXtbIl56Y%3D&reserved=0

inedocs/gcc/Warning-Options.html#index-Wcpp-Werror=cpp;;]

Is anything being done to fix it? I don't see anything in -next or on 
dridevel list recently which it could be.


thanks,
John

Re: radeon driver warning

Hi John,

Am 17.06.22 um 13:52 schrieb John Garry:

Hi Christian,

well, this warning is intentional.

The key point is that your random config results in a very suboptimal
situation where the graphics driver only barely work.

And radeon is pointing that out with this warning. That is totally
expected behavior.

Sure, but I don't think that it should break the build.

well, this doesn't break the build we already have that for years.

What breaks the build now is that warnings are handled as errors.

Can you add a boot-time warning message instead?

Yes, we already have that as well.

And/Or compile out the warning when "warnings = errors"?

That should be doable I think.

Regards,
Christian.

All the best,
John

Regards,
Christian.

Am 17.06.22 um 12:57 schrieb John Garry:

Hi guys,

This warning in the radeon driver breaks my randconfig build on
v5.19-rc2:

drivers/gpu/drm/radeon/radeon_object.c:186:2: error: #warning Please
enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks
to write-combining
[;;https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonl&data=05%7C01%7Cchristian.koenig%40amd.com%7Ca03d7af65a8a4a5bfe4108da5057dec9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637910635599228345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=cRh91K85SllKnVm7pkZEK%2Bv4rbrKCzLkiT%2B9Q5mJ65I%3D&reserved=0

inedocs/gcc/Warning-Options.html#index-Wcpp-Werror=cpp;;]

Is anything being done to fix it? I don't see anything in -next or
on dridevel list recently which it could be.

thanks,
John

[PATCH] drm/aperture: Run fbdev removal before internal helpers

Always run fbdev removal first to remove simpledrm via
sysfb_disable(). This clears the internal state. The later call
to drm_aperture_detach_drivers() then does nothing. Otherwise,
with drm_aperture_detach_drivers() running first, the call to
sysfb_disable() uses inconsistent state.

Example backtrace show below:

[   11.663422] 
==
[   11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0
[   11.663435] Read of size 8 at addr 888108185050 by task systemd-udevd/311
[   11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: GE 5
.19.0-rc2-1-default+ #1689
[   11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011
[   11.663447] Call Trace:
[   11.663449]  
[   11.663451]  ? device_del+0x79/0x5f0
[   11.663456]  dump_stack_lvl+0x5b/0x73
[   11.663462]  print_address_description.constprop.0+0x1f/0x1b0
[   11.663468]  ? device_del+0x79/0x5f0
[   11.663471]  ? device_del+0x79/0x5f0
[   11.663475]  print_report.cold+0x3c/0x21c
[   11.663481]  ? lock_acquired+0x87/0x1e0
[   11.663484]  ? lock_acquired+0x87/0x1e0
[   11.663489]  ? device_del+0x79/0x5f0
[   11.663492]  kasan_report+0xbf/0xf0
[   11.663498]  ? device_del+0x79/0x5f0
[   11.663503]  device_del+0x79/0x5f0
[   11.663509]  ? device_remove_attrs+0x170/0x170
[   11.663514]  ? lock_is_held_type+0xe8/0x140
[   11.663523]  platform_device_del.part.0+0x19/0xe0
[   11.663530]  platform_device_unregister+0x1c/0x30
[   11.663535]  sysfb_disable+0x2d/0x70
[   11.663540]  remove_conflicting_framebuffers+0x1c/0xf0
[   11.663546]  remove_conflicting_pci_framebuffers+0x130/0x1a0
[   11.663554]  drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0
[   11.663561]  ? mgag200_pci_remove+0x30/0x30 [mgag200]
[   11.663578]  mgag200_pci_probe+0x2d/0x140 [mgag200]

Signed-off-by: Thomas Zimmermann 
Fixes: 873eb3b11860 ("fbdev: Disable sysfb device registration when removing 
conflicting FBs")
Cc: Javier Martinez Canillas 
Cc: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: Thomas Zimmermann 
Cc: Alex Deucher 
Cc: Zhen Lei 
Cc: Changcheng Deng 
---
 drivers/gpu/drm/drm_aperture.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index 74bd4a76b253..059fd71424f6 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -329,7 +329,20 @@ int 
drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
 const struct drm_driver 
*req_driver)
 {
resource_size_t base, size;
-   int bar, ret = 0;
+   int bar, ret;
+
+   /*
+* WARNING: Apparently we must kick fbdev drivers before vgacon,
+* otherwise the vga fbdev driver falls over.
+*/
+#if IS_REACHABLE(CONFIG_FB)
+   ret = remove_conflicting_pci_framebuffers(pdev, req_driver->name);
+   if (ret)
+   return ret;
+#endif
+   ret = vga_remove_vgacon(pdev);
+   if (ret)
+   return ret;
 
for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
@@ -339,15 +352,6 @@ int 
drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
drm_aperture_detach_drivers(base, size);
}
 
-   /*
-* WARNING: Apparently we must kick fbdev drivers before vgacon,
-* otherwise the vga fbdev driver falls over.
-*/
-#if IS_REACHABLE(CONFIG_FB)
-   ret = remove_conflicting_pci_framebuffers(pdev, req_driver->name);
-#endif
-   if (ret == 0)
-   ret = vga_remove_vgacon(pdev);
-   return ret;
+   return 0;
 }
 EXPORT_SYMBOL(drm_aperture_remove_conflicting_pci_framebuffers);
-- 
2.36.1

Re: [PATCH] drm/aperture: Run fbdev removal before internal helpers

2022-06-17 Thread Javier Martinez Canillas

[adding Zack and Alex to Cc list]

Hello Thomas,

Thanks a lot for tracking this down and figuring out the root cause!

On 6/17/22 14:10, Thomas Zimmermann wrote:
> Always run fbdev removal first to remove simpledrm via
> sysfb_disable(). This clears the internal state. The later call
> to drm_aperture_detach_drivers() then does nothing. Otherwise,
> with drm_aperture_detach_drivers() running first, the call to
> sysfb_disable() uses inconsistent state.
> 
> Example backtrace show below:
> 
> [   11.663422] 
> ==
> [   11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0
> [   11.663435] Read of size 8 at addr 888108185050 by task 
> systemd-udevd/311
> [   11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: GE
>  5
>   .19.0-rc2-1-default+ #1689
> [   11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011
> [   11.663447] Call Trace:
> [   11.663449]  
> [   11.663451]  ? device_del+0x79/0x5f0
> [   11.663456]  dump_stack_lvl+0x5b/0x73
> [   11.663462]  print_address_description.constprop.0+0x1f/0x1b0
> [   11.663468]  ? device_del+0x79/0x5f0
> [   11.663471]  ? device_del+0x79/0x5f0
> [   11.663475]  print_report.cold+0x3c/0x21c
> [   11.663481]  ? lock_acquired+0x87/0x1e0
> [   11.663484]  ? lock_acquired+0x87/0x1e0
> [   11.663489]  ? device_del+0x79/0x5f0
> [   11.663492]  kasan_report+0xbf/0xf0
> [   11.663498]  ? device_del+0x79/0x5f0
> [   11.663503]  device_del+0x79/0x5f0
> [   11.663509]  ? device_remove_attrs+0x170/0x170
> [   11.663514]  ? lock_is_held_type+0xe8/0x140
> [   11.663523]  platform_device_del.part.0+0x19/0xe0
> [   11.663530]  platform_device_unregister+0x1c/0x30
> [   11.663535]  sysfb_disable+0x2d/0x70
> [   11.663540]  remove_conflicting_framebuffers+0x1c/0xf0
> [   11.663546]  remove_conflicting_pci_framebuffers+0x130/0x1a0
> [   11.663554]  drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0
> [   11.663561]  ? mgag200_pci_remove+0x30/0x30 [mgag200]
> [   11.663578]  mgag200_pci_probe+0x2d/0x140 [mgag200]
> 

Maybe include a Reported-by: Zack Rusin  ? since
this seems to be the exact same issue that he reported yesterday.

Patch looks good to me and this seems to be the correct fix IMO.
That way we won't re-introduce the issue that was fixed by the
sysfb_unregister() function, that is to remove a pdev even if wasn't
bound to a driver to prevent a late simpledrm registration to match.

Reviewed-by: Javier Martinez Canillas 

I wonder what's the best way to coordinate with Alex to merge this
fix and your patch that moves the aperture code out of DRM, since
as far as I can tell both should target the v5.20 release.

> Signed-off-by: Thomas Zimmermann 
> Fixes: 873eb3b11860 ("fbdev: Disable sysfb device registration when removing 
> conflicting FBs")
> Cc: Javier Martinez Canillas 
> Cc: Daniel Vetter 
> Cc: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Helge Deller 
> Cc: Thomas Zimmermann 
> Cc: Alex Deucher 
> Cc: Zhen Lei 
> Cc: Changcheng Deng 
> ---
>  drivers/gpu/drm/drm_aperture.c | 26 +++---
>  1 file changed, 15 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
> index 74bd4a76b253..059fd71424f6 100644
> --- a/drivers/gpu/drm/drm_aperture.c
> +++ b/drivers/gpu/drm/drm_aperture.c
> @@ -329,7 +329,20 @@ int 
> drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
>const struct drm_driver 
> *req_driver)
>  {
>   resource_size_t base, size;
> - int bar, ret = 0;
> + int bar, ret;
> +
> + /*
> +  * WARNING: Apparently we must kick fbdev drivers before vgacon,
> +  * otherwise the vga fbdev driver falls over.
> +  */
> +#if IS_REACHABLE(CONFIG_FB)
> + ret = remove_conflicting_pci_framebuffers(pdev, req_driver->name);
> + if (ret)
> + return ret;
> +#endif
> + ret = vga_remove_vgacon(pdev);
> + if (ret)
> + return ret;
>  
>   for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {
>   if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
> @@ -339,15 +352,6 @@ int 
> drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
>   drm_aperture_detach_drivers(base, size);
>   }
>  
> - /*
> -  * WARNING: Apparently we must kick fbdev drivers before vgacon,
> -  * otherwise the vga fbdev driver falls over.
> -  */
> -#if IS_REACHABLE(CONFIG_FB)
> - ret = remove_conflicting_pci_framebuffers(pdev, req_driver->name);
> -#endif
> - if (ret == 0)
> - ret = vga_remove_vgacon(pdev);
> - return ret;
> + return 0;
>  }
>  EXPORT_SYMBOL(drm_aperture_remove_conflicting_pci_framebuffers);

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [Intel-gfx] [PATCH 08/10] drm/i915/uapi: disable capturing objects on recoverable contexts

2022-06-17 Thread Intel




On 5/25/22 20:43, Matthew Auld wrote:

A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage.

Testcase: igt@gem_exec_capture@capture-recoverable-discrete
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index b279588c0672..e27ccfa50dc3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1961,7 +1961,7 @@ eb_find_first_request_added(struct i915_execbuffer *eb)
  #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
  
  /* Stage with GFP_KERNEL allocations before we enter the signaling critical path */

-static void eb_capture_stage(struct i915_execbuffer *eb)
+static int eb_capture_stage(struct i915_execbuffer *eb)
  {
const unsigned int count = eb->buffer_count;
unsigned int i = count, j;
@@ -1974,6 +1974,10 @@ static void eb_capture_stage(struct i915_execbuffer *eb)
if (!(flags & EXEC_OBJECT_CAPTURE))
continue;
  
+		if (i915_gem_context_is_recoverable(eb->gem_context) &&

+   IS_DGFX(eb->i915))
+   return -EINVAL;
+


We should also require this for future integrated, for capture buffer 
memory allocation purposes.


Otherwise Reviewed-by: Thomas Hellström

Re: [PATCH] drm/aperture: Run fbdev removal before internal helpers


Hi

Am 17.06.22 um 14:29 schrieb Javier Martinez Canillas:

[adding Zack and Alex to Cc list]

Hello Thomas,

Thanks a lot for tracking this down and figuring out the root cause!

On 6/17/22 14:10, Thomas Zimmermann wrote:

Always run fbdev removal first to remove simpledrm via
sysfb_disable(). This clears the internal state. The later call
to drm_aperture_detach_drivers() then does nothing. Otherwise,
with drm_aperture_detach_drivers() running first, the call to
sysfb_disable() uses inconsistent state.

Example backtrace show below:

[   11.663422] 
==
[   11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0
[   11.663435] Read of size 8 at addr 888108185050 by task systemd-udevd/311
[   11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: GE 5
.19.0-rc2-1-default+ #1689
[   11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011
[   11.663447] Call Trace:
[   11.663449]  
[   11.663451]  ? device_del+0x79/0x5f0
[   11.663456]  dump_stack_lvl+0x5b/0x73
[   11.663462]  print_address_description.constprop.0+0x1f/0x1b0
[   11.663468]  ? device_del+0x79/0x5f0
[   11.663471]  ? device_del+0x79/0x5f0
[   11.663475]  print_report.cold+0x3c/0x21c
[   11.663481]  ? lock_acquired+0x87/0x1e0
[   11.663484]  ? lock_acquired+0x87/0x1e0
[   11.663489]  ? device_del+0x79/0x5f0
[   11.663492]  kasan_report+0xbf/0xf0
[   11.663498]  ? device_del+0x79/0x5f0
[   11.663503]  device_del+0x79/0x5f0
[   11.663509]  ? device_remove_attrs+0x170/0x170
[   11.663514]  ? lock_is_held_type+0xe8/0x140
[   11.663523]  platform_device_del.part.0+0x19/0xe0
[   11.663530]  platform_device_unregister+0x1c/0x30
[   11.663535]  sysfb_disable+0x2d/0x70
[   11.663540]  remove_conflicting_framebuffers+0x1c/0xf0
[   11.663546]  remove_conflicting_pci_framebuffers+0x130/0x1a0
[   11.663554]  drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0
[   11.663561]  ? mgag200_pci_remove+0x30/0x30 [mgag200]
[   11.663578]  mgag200_pci_probe+0x2d/0x140 [mgag200]



Maybe include a Reported-by: Zack Rusin  ? since
this seems to be the exact same issue that he reported yesterday.


I'll do.



Patch looks good to me and this seems to be the correct fix IMO.
That way we won't re-introduce the issue that was fixed by the
sysfb_unregister() function, that is to remove a pdev even if wasn't
bound to a driver to prevent a late simpledrm registration to match.

Reviewed-by: Javier Martinez Canillas 


Thanks!



I wonder what's the best way to coordinate with Alex to merge this
fix and your patch that moves the aperture code out of DRM, since
as far as I can tell both should target the v5.20 release.


If nothing else comes in, I'll merge this patch on Monday and send Alex 
an updated version of the vfio patch.


Best regards
Thomas




Signed-off-by: Thomas Zimmermann 
Fixes: 873eb3b11860 ("fbdev: Disable sysfb device registration when removing 
conflicting FBs")
Cc: Javier Martinez Canillas 
Cc: Daniel Vetter 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: Thomas Zimmermann 
Cc: Alex Deucher 
Cc: Zhen Lei 
Cc: Changcheng Deng 
---
  drivers/gpu/drm/drm_aperture.c | 26 +++---
  1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index 74bd4a76b253..059fd71424f6 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -329,7 +329,20 @@ int 
drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
 const struct drm_driver 
*req_driver)
  {
resource_size_t base, size;
-   int bar, ret = 0;
+   int bar, ret;
+
+   /*
+* WARNING: Apparently we must kick fbdev drivers before vgacon,
+* otherwise the vga fbdev driver falls over.
+*/
+#if IS_REACHABLE(CONFIG_FB)
+   ret = remove_conflicting_pci_framebuffers(pdev, req_driver->name);
+   if (ret)
+   return ret;
+#endif
+   ret = vga_remove_vgacon(pdev);
+   if (ret)
+   return ret;
  
  	for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) {

if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM))
@@ -339,15 +352,6 @@ int 
drm_aperture_remove_conflicting_pci_framebuffers(struct pci_dev *pdev,
drm_aperture_detach_drivers(base, size);
}
  
-	/*

-* WARNING: Apparently we must kick fbdev drivers before vgacon,
-* otherwise the vga fbdev driver falls over.
-*/
-#if IS_REACHABLE(CONFIG_FB)
-   ret = remove_conflicting_pci_framebuffers(pdev, req_driver->name);
-#endif
-   if (ret == 0)
-   ret = vga_remove_vgacon(pdev);
-   return ret;
+   return 0;
  }
  EXPORT_SYMBOL(drm_aperture_remove_conflicting_pci_framebuffers);




--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany

Re: [PATCH] drm/aperture: Run fbdev removal before internal helpers

2022-06-17 Thread Zack Rusin

On Fri, 2022-06-17 at 14:41 +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 17.06.22 um 14:29 schrieb Javier Martinez Canillas:
> > [adding Zack and Alex to Cc list]
> > 
> > Hello Thomas,
> > 
> > Thanks a lot for tracking this down and figuring out the root cause!
> > 
> > On 6/17/22 14:10, Thomas Zimmermann wrote:
> > > Always run fbdev removal first to remove simpledrm via
> > > sysfb_disable(). This clears the internal state. The later call
> > > to drm_aperture_detach_drivers() then does nothing. Otherwise,
> > > with drm_aperture_detach_drivers() running first, the call to
> > > sysfb_disable() uses inconsistent state.
> > > 
> > > Example backtrace show below:
> > > 
> > > [   11.663422] 
> > > ==
> > > [   11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0
> > > [   11.663435] Read of size 8 at addr 888108185050 by task 
> > > systemd-udevd/311
> > > [   11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: G
> > > E 5
> > >   .19.0-rc2-1-default+ #1689
> > > [   11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011
> > > [   11.663447] Call Trace:
> > > [   11.663449]  
> > > [   11.663451]  ? device_del+0x79/0x5f0
> > > [   11.663456]  dump_stack_lvl+0x5b/0x73
> > > [   11.663462]  print_address_description.constprop.0+0x1f/0x1b0
> > > [   11.663468]  ? device_del+0x79/0x5f0
> > > [   11.663471]  ? device_del+0x79/0x5f0
> > > [   11.663475]  print_report.cold+0x3c/0x21c
> > > [   11.663481]  ? lock_acquired+0x87/0x1e0
> > > [   11.663484]  ? lock_acquired+0x87/0x1e0
> > > [   11.663489]  ? device_del+0x79/0x5f0
> > > [   11.663492]  kasan_report+0xbf/0xf0
> > > [   11.663498]  ? device_del+0x79/0x5f0
> > > [   11.663503]  device_del+0x79/0x5f0
> > > [   11.663509]  ? device_remove_attrs+0x170/0x170
> > > [   11.663514]  ? lock_is_held_type+0xe8/0x140
> > > [   11.663523]  platform_device_del.part.0+0x19/0xe0
> > > [   11.663530]  platform_device_unregister+0x1c/0x30
> > > [   11.663535]  sysfb_disable+0x2d/0x70
> > > [   11.663540]  remove_conflicting_framebuffers+0x1c/0xf0
> > > [   11.663546]  remove_conflicting_pci_framebuffers+0x130/0x1a0
> > > [   11.663554]  drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0
> > > [   11.663561]  ? mgag200_pci_remove+0x30/0x30 [mgag200]
> > > [   11.663578]  mgag200_pci_probe+0x2d/0x140 [mgag200]
> > > 
> > 
> > Maybe include a Reported-by: Zack Rusin  ? since
> > this seems to be the exact same issue that he reported yesterday.
> 
> I'll do.
> 
> > 
> > Patch looks good to me and this seems to be the correct fix IMO.
> > That way we won't re-introduce the issue that was fixed by the
> > sysfb_unregister() function, that is to remove a pdev even if wasn't
> > bound to a driver to prevent a late simpledrm registration to match.
> > 
> > Reviewed-by: Javier Martinez Canillas 
> 
> Thanks!
> 
> > 
> > I wonder what's the best way to coordinate with Alex to merge this
> > fix and your patch that moves the aperture code out of DRM, since
> > as far as I can tell both should target the v5.20 release.
> 
> If nothing else comes in, I'll merge this patch on Monday and send Alex 
> an updated version of the vfio patch.

Thanks Thomas. I just tested it on our arm64 configs and it fixes the crash on 
boot
we've been seeing and gets them running again.

Reviewed-by: Zack Rusin 

z

Re: radeon driver warning


Hi John,

Am 17.06.22 um 14:01 schrieb John Garry:

On 17/06/2022 12:57, Christian König wrote:


And/Or compile out the warning when "warnings = errors"?


That should be doable I think.


ok, if something can be done then I would appreciate it. I do much 
randconfig builds as part of my upstream process and anything breaking 
is a bit of a pain.


I've just double checked the code and we have already wrapped the 
warning into "#ifndef CONFIG_COMPILE_TEST".


So the question is why does your random config not set CONFIG_COMPILE_TEST?

Regards,
Christian.



Thanks!

Re: [RFC PATCH 3/5] drm/amdgpu: Allow explicit sync for VM ops.

2022-06-17 Thread Bas Nieuwenhuizen

On Wed, Jun 15, 2022 at 9:00 AM Christian König
 wrote:
>
> Am 06.06.22 um 13:00 schrieb Bas Nieuwenhuizen:
> > On Mon, Jun 6, 2022 at 12:35 PM Christian König
> >  wrote:
> >> [SNIP]
> >> That part won't work at all and would cause additional synchronization
> >> problems.
> >>
> >> First of all for implicit synced CS we should use READ, not BOOKKEEP.
> >> Because BOOKKEEP would incorrectly be ignored by OpenGL importers. I've
> >> fixed that this causes memory corruption, but it is still nice to avoid.
> > Yes, what I'm saying is that on implicit sync CS submission should add
> > READ fences to the dma resv and on explicit sync CS submission should
> > add BOOKKEEP fences.
>
> No, exactly that is wrong.
>
> Implicit CS submissions should add WRITE fences.
>
> Explicit CS submissions should add READ fences.
>
> Only VM updates should add BOOKKEEP fences.
>
> >> BOOKKEEP can only be used by VM updates themselves. So that they don't
> >> interfere with CS.
> > That is the point why we would go BOOKKEEP for explicit sync CS
> > submissions, no? Explicit submission shouldn't interfere with any
> > other CS submissions. That includes being totally ignored by GL
> > importers (if we want to have synchronization there between an
> > explicit submission and GL, userspace is expected to use Jason's
> > dmabuf fence import/export IOCTLs)
>
> No, that would break existing DMA-buf rules.
>
> Explicit CS submissions are still a dependency for implicit submissions.

This is explicitly what we don't want for explicit submissions and why
I waited with this series until the DMA_RESV_USAGE series landed. We
wish to opt out from implicit sync completely, and just use the IOCTLs
Jason wrote for back-compat with windowing systems that need it.

If BOOKKEEP isn't for that, should we add a new USAGE?

>
> >
> > Then the second problem is that the VM IOCTL has absolutely no idea what
> > the CS IOCTL would be doing. That's why we have added the EXPLICIT sync
> > flag on the BO.
> > It doesn't need to? We just use a different sync_mode for BOOKKEEP
> > fences vs others:
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fpatch%2F487887%2F%3Fseries%3D104578%26rev%3D2&data=05%7C01%7Cchristian.koenig%40amd.com%7C81db0fea1c854076fc4408da47abafaa%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637901099957139870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=F72Boaesx83MD2pjGuucA1buawi205XLSsQHg5EH39A%3D&reserved=0
>
> No, exactly that's completely broken.
>
> Regards,
> Christian.
>
> >
> > (the nice thing about doing it this way is that it is independent of
> > the IOCTL, i.e. also works for the delayed mapping changes we trigger
> > on CS submit)
> >
> >> Regards,
> >> Christian.
> >>
>  That should be doable, but then you don't need any of the other changes.
> 
>  Regards,
>  Christian.
> 
> >> #1 Is rather easy to fix, you just need to copy all dma_fences from the
> >> page table dma_resv object over to the BOs dma_resv object in the gem
> >> close handler. E.g. exactly what you suggested with the dma_resv_copy
> >> function.
> >>
> >> #2 is a nightmare.
> >>
> >> We can't move the TLB flush at the end of the unmap operation because 
> >> on
> >> async TLB flushes are either a bit complicated (double flushes etc..) 
> >> or
> >> don't even work at all because of hw bugs. So to have a reliable TLB
> >> flush we must make sure that nothing else is ongoing and that means
> >> CS->VM->CS barrier.
> >>
> >> We try very hard to circumvent that already on maps by (for example)
> >> using a completely new VMID for CS after the VM map operation.
> >>
> >> But for the unmap operation we would need some kind special dma_fence
> >> implementation which would not only wait for all existing dma_fence but
> >> also for the one added until the unmap operation is completed. Cause
> >> otherwise our operation we do at #1 would simply not catch all
> >> dma_fences which have access to the memory.
> >>
> >> That's certainly doable, but I think just using the drm_exec stuff I
> >> already came up with is easier.
> >>
> >> When we can grab locks for all the BOs involved amdgpu_vm_clear_freed()
> >> goes away and we can keep track of the unmap operations in the bo_va
> >> structure.
> >>
> >> With that done you can make the explicit sync you noted in the bo_va
> >> structure and implicit sync when the bo_va structure goes away.
> >>
> >> Then the only reason I can see why we would need a CS->VM dependency is
> >> implicit synchronization, and that's what we are trying to avoid here 
> >> in
> >> the first place.
> >>
> >> Regards,
> >> Christian.
> >>
>  To get rid of this barrier you must first fix the part where CS
>  submissions wait for the

Re: [RFC PATCH 3/5] drm/amdgpu: Allow explicit sync for VM ops.


Am 17.06.22 um 15:03 schrieb Bas Nieuwenhuizen:

[SNIP]

BOOKKEEP can only be used by VM updates themselves. So that they don't
interfere with CS.

That is the point why we would go BOOKKEEP for explicit sync CS
submissions, no? Explicit submission shouldn't interfere with any
other CS submissions. That includes being totally ignored by GL
importers (if we want to have synchronization there between an
explicit submission and GL, userspace is expected to use Jason's
dmabuf fence import/export IOCTLs)

No, that would break existing DMA-buf rules.

Explicit CS submissions are still a dependency for implicit submissions.

This is explicitly what we don't want for explicit submissions and why
I waited with this series until the DMA_RESV_USAGE series landed. We
wish to opt out from implicit sync completely, and just use the IOCTLs
Jason wrote for back-compat with windowing systems that need it.

If BOOKKEEP isn't for that, should we add a new USAGE?


BOOKKEEP is exactly for that, but as discussed with Daniel that's not 
what we want in the kernel.


When you mix implicit with explicit synchronization (OpenGL with RADV 
for example) it should be mandatory for the OpenGL to wait for any RADV 
submission before issuing an operation.


What you want to do is intentionally not supported.

Regards,
Christian.

Re: [PATCH 2/2] arm64: dts: mt8183: Add panel rotation


Hi Hsin-Yi Wang,

On 06/06/2022 17:29, Hsin-Yi Wang wrote:

On Mon, May 30, 2022 at 7:30 PM Hsin-Yi Wang  wrote:


krane, kakadu, and kodama boards have a default panel rotation.

Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Enric Balletbo i Serra 
Tested-by: Enric Balletbo i Serra 
---


Hi Matthias,

The series ("Add a panel API to return panel orientation") might land
in drm-misc. With this series applied, we can add this patch to give
the correct default orientation for mt8183 kukui devices.
I didn't send this patch again with the series, since they might land
in different trees.



I had a look on Linux next (next-20220617) and wasn't able to find the mtk_dsi.c 
changes. What is the status of this?


Regards,
Matthias


Thanks.


  arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
index 8d5bf73a9099..f0dd5a06629d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
@@ -276,6 +276,7 @@ panel: panel@0 {
 avee-supply = <&ppvarp_lcd>;
 pp1800-supply = <&pp1800_lcd>;
 backlight = <&backlight_lcd0>;
+   rotation = <270>;
 port {
 panel_in: endpoint {
 remote-endpoint = <&dsi_out>;
--
2.36.1.124.g0e6072fb45-goog

Re: [PATCH] drm/aperture: Run fbdev removal before internal helpers

2022-06-17 Thread Alex Williamson

On Fri, 17 Jun 2022 14:41:01 +0200
Thomas Zimmermann  wrote:

> Hi
> 
> Am 17.06.22 um 14:29 schrieb Javier Martinez Canillas:
> > [adding Zack and Alex to Cc list]
> > 
> > Hello Thomas,
> > 
> > Thanks a lot for tracking this down and figuring out the root cause!
> > 
> > On 6/17/22 14:10, Thomas Zimmermann wrote:  
> >> Always run fbdev removal first to remove simpledrm via
> >> sysfb_disable(). This clears the internal state. The later call
> >> to drm_aperture_detach_drivers() then does nothing. Otherwise,
> >> with drm_aperture_detach_drivers() running first, the call to
> >> sysfb_disable() uses inconsistent state.
> >>
> >> Example backtrace show below:
> >>
> >> [   11.663422] 
> >> ==
> >> [   11.663426] BUG: KASAN: use-after-free in device_del+0x79/0x5f0
> >> [   11.663435] Read of size 8 at addr 888108185050 by task 
> >> systemd-udevd/311
> >> [   11.663440] CPU: 0 PID: 311 Comm: systemd-udevd Tainted: GE 
> >> 5
> >>.19.0-rc2-1-default+ #1689
> >> [   11.663445] Hardware name: HP ProLiant DL120 G7, BIOS J01 04/21/2011
> >> [   11.663447] Call Trace:
> >> [   11.663449]  
> >> [   11.663451]  ? device_del+0x79/0x5f0
> >> [   11.663456]  dump_stack_lvl+0x5b/0x73
> >> [   11.663462]  print_address_description.constprop.0+0x1f/0x1b0
> >> [   11.663468]  ? device_del+0x79/0x5f0
> >> [   11.663471]  ? device_del+0x79/0x5f0
> >> [   11.663475]  print_report.cold+0x3c/0x21c
> >> [   11.663481]  ? lock_acquired+0x87/0x1e0
> >> [   11.663484]  ? lock_acquired+0x87/0x1e0
> >> [   11.663489]  ? device_del+0x79/0x5f0
> >> [   11.663492]  kasan_report+0xbf/0xf0
> >> [   11.663498]  ? device_del+0x79/0x5f0
> >> [   11.663503]  device_del+0x79/0x5f0
> >> [   11.663509]  ? device_remove_attrs+0x170/0x170
> >> [   11.663514]  ? lock_is_held_type+0xe8/0x140
> >> [   11.663523]  platform_device_del.part.0+0x19/0xe0
> >> [   11.663530]  platform_device_unregister+0x1c/0x30
> >> [   11.663535]  sysfb_disable+0x2d/0x70
> >> [   11.663540]  remove_conflicting_framebuffers+0x1c/0xf0
> >> [   11.663546]  remove_conflicting_pci_framebuffers+0x130/0x1a0
> >> [   11.663554]  drm_aperture_remove_conflicting_pci_framebuffers+0x86/0xb0
> >> [   11.663561]  ? mgag200_pci_remove+0x30/0x30 [mgag200]
> >> [   11.663578]  mgag200_pci_probe+0x2d/0x140 [mgag200]
> >>  
> > 
> > Maybe include a Reported-by: Zack Rusin  ? since
> > this seems to be the exact same issue that he reported yesterday.  
> 
> I'll do.
> 
> > 
> > Patch looks good to me and this seems to be the correct fix IMO.
> > That way we won't re-introduce the issue that was fixed by the
> > sysfb_unregister() function, that is to remove a pdev even if wasn't
> > bound to a driver to prevent a late simpledrm registration to match.
> > 
> > Reviewed-by: Javier Martinez Canillas   
> 
> Thanks!
> 
> > 
> > I wonder what's the best way to coordinate with Alex to merge this
> > fix and your patch that moves the aperture code out of DRM, since
> > as far as I can tell both should target the v5.20 release.  
> 
> If nothing else comes in, I'll merge this patch on Monday and send Alex 
> an updated version of the vfio patch.

Please also publish a topic branch for the base of that patch if you're
still looking for the non-drm aperture + vfio series to go in through my
vfio tree.  Thanks,

Alex

Re: [PATCH 2/2] arm64: dts: mt8183: Add panel rotation

2022-06-17 Thread Hsin-Yi Wang

On Fri, Jun 17, 2022 at 10:10 PM Matthias Brugger
 wrote:
>
> Hi Hsin-Yi Wang,
>
> On 06/06/2022 17:29, Hsin-Yi Wang wrote:
> > On Mon, May 30, 2022 at 7:30 PM Hsin-Yi Wang  wrote:
> >>
> >> krane, kakadu, and kodama boards have a default panel rotation.
> >>
> >> Signed-off-by: Hsin-Yi Wang 
> >> Reviewed-by: Enric Balletbo i Serra 
> >> Tested-by: Enric Balletbo i Serra 
> >> ---
> >
> > Hi Matthias,
> >
> > The series ("Add a panel API to return panel orientation") might land
> > in drm-misc. With this series applied, we can add this patch to give
> > the correct default orientation for mt8183 kukui devices.
> > I didn't send this patch again with the series, since they might land
> > in different trees.
> >
>
> I had a look on Linux next (next-20220617) and wasn't able to find the 
> mtk_dsi.c
> changes. What is the status of this?
>
The mtk_dsi change got dropped. The latest is this series:
https://lore.kernel.org/lkml/20220609072722.3488207-1-hsi...@chromium.org/,
still waiting to be picked or others' comments.

If the dts patch is picked without the drm series, there will be a
WARN, but won't affect boot or display up.


> Regards,
> Matthias
>
> > Thanks.
> >
> >>   arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi 
> >> b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> >> index 8d5bf73a9099..f0dd5a06629d 100644
> >> --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> >> +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi
> >> @@ -276,6 +276,7 @@ panel: panel@0 {
> >>  avee-supply = <&ppvarp_lcd>;
> >>  pp1800-supply = <&pp1800_lcd>;
> >>  backlight = <&backlight_lcd0>;
> >> +   rotation = <270>;
> >>  port {
> >>  panel_in: endpoint {
> >>  remote-endpoint = <&dsi_out>;
> >> --
> >> 2.36.1.124.g0e6072fb45-goog
> >>

Re: [Intel-gfx] [PATCH 07/10] drm/i915/error: skip non-mappable pages

2022-06-17 Thread Intel




On 5/25/22 20:43, Matthew Auld wrote:

Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.

Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/i915_gpu_error.c | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 0512c66fa4f3..77df899123c2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -1116,11 +1116,15 @@ i915_vma_coredump_create(const struct intel_gt *gt,
dma_addr_t dma;
  
  		for_each_sgt_daddr(dma, iter, vma_res->bi.pages) {

+   dma_addr_t offset = dma - mem->region.start;
void __iomem *s;
  
-			s = io_mapping_map_wc(&mem->iomap,

- dma - mem->region.start,
- PAGE_SIZE);
+   if (offset + PAGE_SIZE > mem->io_size) {
+   ret = -EINVAL;
+   break;
+   }
+
+   s = io_mapping_map_wc(&mem->iomap, offset, PAGE_SIZE);
ret = compress_page(compress,
(void __force *)s, dst,
true);


Reviewed-by: Thomas Hellström

Re: [Intel-gfx] [PATCH 06/10] drm/i915/uapi: add NEEDS_CPU_ACCESS hint

2022-06-17 Thread Intel




On 5/25/22 20:43, Matthew Auld wrote:

If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't make space.

Testcase: igt@gem-create@create-ext-cpu-access-sanity-check
Testcase: igt@gem-create@create-ext-cpu-access-big
Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gem/i915_gem_create.c | 26 ++---
  include/uapi/drm/i915_drm.h| 61 +++---
  2 files changed, 71 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index d094cae0ddf1..33673fe7ee0a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -241,6 +241,7 @@ struct create_ext {
struct drm_i915_private *i915;
struct intel_memory_region *placements[INTEL_REGION_UNKNOWN];
unsigned int n_placements;
+   unsigned int placement_mask;
unsigned long flags;
  };
  
@@ -337,6 +338,7 @@ static int set_placements(struct drm_i915_gem_create_ext_memory_regions *args,

for (i = 0; i < args->num_regions; i++)
ext_data->placements[i] = placements[i];
  
+	ext_data->placement_mask = mask;

return 0;
  
  out_dump:

@@ -411,7 +413,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_object *obj;
int ret;
  
-	if (args->flags)

+   if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
  
  	ret = i915_user_extensions(u64_to_user_ptr(args->extensions),

@@ -427,13 +429,21 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
ext_data.n_placements = 1;
}
  
-	/*

-* TODO: add a userspace hint to force CPU_ACCESS for the object, which
-* can override this.
-*/
-   if (ext_data.n_placements > 1 ||
-   ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
-   ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+   if (args->flags & I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) {
+   if (ext_data.n_placements == 1)
+   return -EINVAL;
+
+   /*
+* We always need to be able to spill to system memory, if we
+* can't place in the mappable part of LMEM.
+*/
+   if (!(ext_data.placement_mask & BIT(INTEL_REGION_SMEM)))
+   return -EINVAL;
+   } else {
+   if (ext_data.n_placements > 1 ||
+   ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
+   ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+   }
  
  	obj = __i915_gem_object_create_user_ext(i915, args->size,

ext_data.placements,
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index e30f31a440b3..5b0a10e6a1b8 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3366,11 +3366,11 @@ struct drm_i915_query_memory_regions {
   * struct drm_i915_gem_create_ext - Existing gem_create behaviour, with added
   * extension support using struct i915_user_extension.
   *
- * Note that in the future we want to have our buffer flags here, at least for
- * the stuff that is immutable. Previously we would have two ioctls, one to
- * create the object with gem_create, and another to apply various parameters,
- * however this creates some ambiguity for the params which are considered
- * immutable. Also in general we're phasing out the various SET/GET ioctls.
+ * Note that new buffer flags should be added here, at least for the stuff that
+ * is immutable. Previously we would have two ioctls, one to create the object
+ * with gem_create, and another to apply various parameters, however this
+ * creates some ambiguity for the params which are considered immutable. Also 
in
+ * general we're phasing out the various SET/GET ioctls.
   */
  struct drm_i915_gem_create_ext {
/**
@@ -3378,7 +3378,6 @@ struct drm_i915_gem_create_ext {
 *
 * The (page-aligned) allocated size for the object will be returned.
 *
-*
 * DG2 64K min page size implications:
 *
 * On discrete platforms, starting from DG2, we have to contend with GTT
@@ -3390,7 +3389,9 @@ struct drm_i915_gem_create_ext {
 *
 * 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.
+* such as DG2. The kernel will always select the largest

Re: [PATCH v2 2/2] drm/i915/gt: Cleanup interface for MCR operations

2022-06-17 Thread Matt Roper

On Fri, Jun 17, 2022 at 06:57:20AM -0700, Harish Chegondi wrote:
> On Tue, Jun 14, 2022 at 05:10:19PM -0700, Matt Roper wrote:
> > Let's replace the assortment of intel_gt_* and intel_uncore_* functions
> > that operate on MCR registers with a cleaner set of interfaces:
> > 
> >   * intel_gt_mcr_read -- unicast read from specific instance
> >   * intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated
> > instance
> >   * intel_gt_mcr_unicast_write -- unicast write to specific instance
> >   * intel_gt_mcr_multicast_write[_fw] -- multicast write to all instances
> > 
> > We'll also replace the historic "slice" and "subslice" terminology with
> > "group" and "instance" to match the documentation for more recent
> > platforms; these days MCR steering applies to more types of replication
> > than just slice/subslice.
> > 
> > v2:
> >  - Reference the new kerneldoc from i915.rst.  (Jani)
> >  - Tweak the wording of the documentation for a couple functions to
> >clarify the difference between "_fw" and non-"_fw" forms.
> > 
> > Signed-off-by: Matt Roper 
> > Acked-by: Jani Nikula 
> > ---
> >  Documentation/gpu/i915.rst  |  12 +
> >  drivers/gpu/drm/i915/gem/i915_gem_stolen.c  |   2 +-
> >  drivers/gpu/drm/i915/gt/intel_engine_cs.c   |  33 ++-
> >  drivers/gpu/drm/i915/gt/intel_gt_debugfs.c  |   2 +-
> >  drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 239 
> >  drivers/gpu/drm/i915/gt/intel_gt_mcr.h  |  43 ++--
> >  drivers/gpu/drm/i915/gt/intel_region_lmem.c |   4 +-
> >  drivers/gpu/drm/i915/gt/intel_workarounds.c |   8 +-
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  |   2 +-
> >  9 files changed, 200 insertions(+), 145 deletions(-)
> > 
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 54060cd6c419..4e59db1cfb00 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -246,6 +246,18 @@ Display State Buffer
> >  .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
> > :internal:
> >  
> > +GT Programming
> > +==
> > +
> > +Multicast/Replicated (MCR) Registers
> > +
> > +
> > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +   :doc: GT Multicast/Replicated (MCR) Register Support
> > +
> > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> > +   :internal:
> > +
> >  Memory Management and Command Submission
> >  
> >  
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > index da30503d3ca2..fa54823d1219 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> > @@ -835,7 +835,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private 
> > *i915, u16 type,
> > } else {
> > resource_size_t lmem_range;
> >  
> > -   lmem_range = intel_gt_read_register(&i915->gt0, 
> > XEHPSDV_TILE0_ADDR_RANGE) & 0x;
> > +   lmem_range = intel_gt_mcr_read_any(&i915->gt0, 
> > XEHPSDV_TILE0_ADDR_RANGE) & 0x;
> > lmem_size = lmem_range >> XEHPSDV_TILE_LMEM_RANGE_SHIFT;
> > lmem_size *= SZ_1G;
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 244af1bdb7db..136cc44c3deb 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -1428,14 +1428,6 @@ void intel_engine_cancel_stop_cs(struct 
> > intel_engine_cs *engine)
> > ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
> >  }
> >  
> > -static u32
> > -read_subslice_reg(const struct intel_engine_cs *engine,
> > - int slice, int subslice, i915_reg_t reg)
> > -{
> > -   return intel_uncore_read_with_mcr_steering(engine->uncore, reg,
> > -  slice, subslice);
> > -}
> > -
> >  /* NB: please notice the memset */
> >  void intel_engine_get_instdone(const struct intel_engine_cs *engine,
> >struct intel_instdone *instdone)
> > @@ -1469,28 +1461,33 @@ void intel_engine_get_instdone(const struct 
> > intel_engine_cs *engine,
> > if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> > for_each_instdone_gslice_dss_xehp(i915, sseu, iter, 
> > slice, subslice) {
> > instdone->sampler[slice][subslice] =
> > -   read_subslice_reg(engine, slice, 
> > subslice,
> > - 
> > GEN7_SAMPLER_INSTDONE);
> > +   intel_gt_mcr_read(engine->gt,
> > + GEN7_SAMPLER_INSTDONE,
> > + slice, subslice);
> > instdone->row[slice][subslice] =
> > -

Re: [Intel-gfx] [PATCH 04/10] drm/i915: remove intel_memory_region avail

2022-06-17 Thread Thomas Hellström




On 5/25/22 20:43, Matthew Auld wrote:

No longer used.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/intel_memory_region.c | 4 +---
  drivers/gpu/drm/i915/intel_memory_region.h | 1 -
  2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index 94ee26e99549..9a4a7fb55582 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -198,8 +198,7 @@ void intel_memory_region_debug(struct intel_memory_region 
*mr,
if (mr->region_private)
ttm_resource_manager_debug(mr->region_private, printer);
else
-   drm_printf(printer, "total:%pa, available:%pa bytes\n",
-  &mr->total, &mr->avail);
+   drm_printf(printer, "total:%pa bytes\n", &mr->total);
  }
  
  static int intel_memory_region_memtest(struct intel_memory_region *mem,

@@ -242,7 +241,6 @@ intel_memory_region_create(struct drm_i915_private *i915,
mem->min_page_size = min_page_size;
mem->ops = ops;
mem->total = size;
-   mem->avail = mem->total;
mem->type = type;
mem->instance = instance;
  
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h b/drivers/gpu/drm/i915/intel_memory_region.h

index 2214f251bec3..2953ed5c3248 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -75,7 +75,6 @@ struct intel_memory_region {
resource_size_t io_size;
resource_size_t min_page_size;
resource_size_t total;
-   resource_size_t avail;
  
  	u16 type;

u16 instance;


Reviewed-by: Thomas Hellström

Re: [Intel-gfx] [PATCH 09/10] drm/i915: turn on small BAR support

2022-06-17 Thread Thomas Hellström




On 5/25/22 20:43, Matthew Auld wrote:

With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Lionel Landwerlin 
Cc: Tvrtko Ursulin 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: Akeem G Abodunrin 
---
  drivers/gpu/drm/i915/gt/intel_region_lmem.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c 
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index e9c12e0d6f59..6c6f8cbd7321 100644
--- a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
+++ b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
@@ -111,12 +111,6 @@ static struct intel_memory_region *setup_lmem(struct 
intel_gt *gt)
flat_ccs_base = intel_gt_read_register(gt, 
XEHPSDV_FLAT_CCS_BASE_ADDR);
flat_ccs_base = (flat_ccs_base >> XEHPSDV_CCS_BASE_SHIFT) * 
SZ_64K;
  
-		/* FIXME: Remove this when we have small-bar enabled */

-   if (pci_resource_len(pdev, 2) < lmem_size) {
-   drm_err(&i915->drm, "System requires small-BAR support, 
which is currently unsupported on this kernel\n");
-   return ERR_PTR(-EINVAL);
-   }
-
if (GEM_WARN_ON(lmem_size < flat_ccs_base))
return ERR_PTR(-EIO);
  
@@ -169,6 +163,10 @@ static struct intel_memory_region *setup_lmem(struct intel_gt *gt)

drm_info(&i915->drm, "Local memory available: %pa\n",
 &lmem_size);
  
+	if (io_size < lmem_size)

+   drm_info(&i915->drm, "Using a reduced BAR size of %lluMiB. Consider 
enabling the full BAR size if available in the BIOS.\n",
+(u64)io_size >> 20);
+


Hmm. I wonder what BIOS uis typically call the mappable portion of VRAM. 
I'll se if I can check that on my DG1 system. Might be that an average 
user misinterprets "full BAR".


/Thomas




return mem;
  
  err_region_put:

Re: [PATCH v2 8/9] drm/i915/xehpsdv: Store lmem region in gt

2022-06-17 Thread Andi Shyti

Hi,

On Thu, Jun 16, 2022 at 05:31:05PM +0530, Anshuman Gupta wrote:
> From: Tvrtko Ursulin 
> 
> Store a pointer to respective local memory region in intel_gt so it can be
> used when memory local to a GT needs to be allocated.
> 
> Cc: Andi Shyti 
> Signed-off-by: Tvrtko Ursulin 
> Signed-off-by: Anshuman Gupta 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt.c   | 1 +
>  drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index f33290358c51..7a535f670ae1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -91,6 +91,7 @@ static int intel_gt_probe_lmem(struct intel_gt *gt)
>   GEM_BUG_ON(!HAS_REGION(i915, id));
>   GEM_BUG_ON(i915->mm.regions[id]);
>   i915->mm.regions[id] = mem;
> + gt->lmem = mem;
>  
>   return 0;
>  }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index df708802889d..cd7744eaaeaa 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -23,6 +23,7 @@
>  #include "intel_gt_buffer_pool_types.h"
>  #include "intel_hwconfig.h"
>  #include "intel_llc_types.h"
> +#include "intel_memory_region.h"
>  #include "intel_reset_types.h"
>  #include "intel_rc6_types.h"
>  #include "intel_rps_types.h"
> @@ -202,6 +203,8 @@ struct intel_gt {
>*/
>   phys_addr_t phys_addr;
>  
> + struct intel_memory_region *lmem;
> +

this was somewhere in my next patch that is getting very
delayed... anyway, with Jani's include note:

Reviewed-by: Andi Shyti 

Thanks,
Andi

>   struct intel_gt_info {
>   unsigned int id;
>  
> -- 
> 2.26.2

[PATCH v4] drm/i915: Improve on suspend / resume time with VT-d enabled

2022-06-17 Thread Thomas Hellström

When DMAR / VT-d is enabled, the display engine uses overfetching,
presumably to deal with the increased latency. To avoid display engine
errors and DMAR faults, as a workaround the GGTT is populated with scatch
PTEs when VT-d is enabled. However starting with gen10, Write-combined
writing of scratch PTES is no longer possible and as a result, populating
the full GGTT with scratch PTEs like on resume becomes very slow as
uncached access is needed.

Therefore, on integrated GPUs utilize the fact that the PTEs are stored in
stolen memory which retain content across S3 suspend. Don't clear the PTEs
on suspend and resume. This improves on resume time with around 100 ms.
While 100+ms might appear like a short time it's 10% to 20% of total resume
time and important in some applications.

One notable exception is Intel Rapid Start Technology which may cause
stolen memory to be lost across what the OS percieves as S3 suspend.
If IRST is enabled or if we can't detect whether IRST is enabled, retain
the old workaround, clearing and re-instating PTEs.

As an additional measure, if we detect that the last ggtt pte was lost
during suspend, print a warning and re-populate the GGTT ptes

On discrete GPUs, the display engine scans out from LMEM which isn't
subject to DMAR, and presumably the workaround is therefore not needed,
but that needs to be verified and disabling the workaround for dGPU,
if possible, will be deferred to a follow-up patch.

v2:
- Rely on retained ptes to also speed up suspend and resume re-binding.
- Re-build GGTT ptes if Intel rst is enabled.
v3:
- Re-build GGTT ptes also if we can't detect whether Intel rst is enabled,
  and if the guard page PTE and end of GGTT was lost.
v4:
- Fix some kerneldoc issues (Matthew Auld), rebase.

Signed-off-by: Thomas Hellström 
Acked-by: Daniel Vetter 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 56 +---
 drivers/gpu/drm/i915/gt/intel_gtt.h  | 24 
 drivers/gpu/drm/i915/i915_driver.c   | 16 
 3 files changed, 90 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index e6b2eb122ad7..0849a6f66309 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -22,6 +22,13 @@
 #include "intel_gtt.h"
 #include "gen8_ppgtt.h"
 
+static inline bool suspend_retains_ptes(struct i915_address_space *vm)
+{
+   return GRAPHICS_VER(vm->i915) >= 8 &&
+   !HAS_LMEM(vm->i915) &&
+   vm->is_ggtt;
+}
+
 static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
   unsigned long color,
   u64 *start,
@@ -93,6 +100,23 @@ int i915_ggtt_init_hw(struct drm_i915_private *i915)
return 0;
 }
 
+/*
+ * Return the value of the last GGTT pte cast to an u64, if
+ * the system is supposed to retain ptes across resume. 0 otherwise.
+ */
+static u64 read_last_pte(struct i915_address_space *vm)
+{
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
+   gen8_pte_t __iomem *ptep;
+
+   if (!suspend_retains_ptes(vm))
+   return 0;
+
+   GEM_BUG_ON(GRAPHICS_VER(vm->i915) < 8);
+   ptep = (typeof(ptep))ggtt->gsm + (ggtt_total_entries(ggtt) - 1);
+   return readq(ptep);
+}
+
 /**
  * i915_ggtt_suspend_vm - Suspend the memory mappings for a GGTT or DPT VM
  * @vm: The VM to suspend the mappings for
@@ -156,7 +180,10 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
i915_gem_object_unlock(obj);
}
 
-   vm->clear_range(vm, 0, vm->total);
+   if (!suspend_retains_ptes(vm))
+   vm->clear_range(vm, 0, vm->total);
+   else
+   i915_vm_to_ggtt(vm)->probed_pte = read_last_pte(vm);
 
vm->skip_pte_rewrite = save_skip_rewrite;
 
@@ -299,6 +326,8 @@ static int init_ggtt(struct i915_ggtt *ggtt)
struct drm_mm_node *entry;
int ret;
 
+   ggtt->pte_lost = true;
+
/*
 * GuC requires all resources that we're sharing with it to be placed in
 * non-WOPCM memory. If GuC is not present or not in use we still need a
@@ -675,11 +704,20 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
 {
struct i915_vma *vma;
bool write_domain_objs = false;
+   bool retained_ptes;
 
drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
 
-   /* First fill our portion of the GTT with scratch pages */
-   vm->clear_range(vm, 0, vm->total);
+   /*
+* First fill our portion of the GTT with scratch pages if
+* they were not retained across suspend.
+*/
+   retained_ptes = suspend_retains_ptes(vm) &&
+   !i915_vm_to_ggtt(vm)->pte_lost &&
+   !GEM_WARN_ON(i915_vm_to_ggtt(vm)->probed_pte != 
read_last_pte(vm));
+
+   if (!retained_ptes)
+   vm->clear_range(vm, 0, vm->total);
 
/* clflush objects bou

Re: [Intel-gfx] [PATCH 1/2] iosys-map: Add per-word read

2022-06-17 Thread Lucas De Marchi


On Fri, Jun 17, 2022 at 01:52:03AM -0700, Lucas De Marchi wrote:

Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.

Employ a similar trick as __seqprop() by using _Generic() to generate
only the specific call based on a type-compatible variable.

For a pariticular i915 workload producing GPU context switches,
__get_engine_usage_record() is particularly hot since the engine usage
is read from device local memory with dgfx, possibly multiple times
since it's racy. Test execution time for this test shows a ~12.5%
improvement with DG2:

Before:
nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07;
median = 9.52548e+06; var = 526149;
After:
nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06;
median = 8.33955e+06; var = 333113;

Other things attempted that didn't prove very useful:
1) Change the _Generic() on x86 to just dereference the memory address
2) Change __get_engine_usage_record() to do just 1 read per loop,
  comparing with the previous value read
3) Change __get_engine_usage_record() to access the fields directly as it
  was before the conversion to iosys-map

(3) did gave a small improvement (~3%), but doesn't seem to scale well
to other similar cases in the driver.

Additional test by Chris Wilson using gem_create from igt with some
changes to track object creation time. This happens to accidentally
stress this code path:

Pre iosys_map conversion of engine busyness:
lmem0: Creating262144 4KiB objects took 59274.2ms

Unpatched:
lmem0: Creating262144 4KiB objects took 108830.2ms

With readl (this patch):
lmem0: Creating262144 4KiB objects took 61348.6ms

s/readl/READ_ONCE/
lmem0: Creating262144 4KiB objects took 61333.2ms

So we do take a little bit more time than before the conversion, but
that is due to other factors: bringing the READ_ONCE back would be as
good as just doing this conversion.

v2:
- Remove default from _Generic() - callers wanting to read more
 than u64 should use iosys_map_memcpy_from()
- Add READ_ONCE() cases dereferencing the pointer when using system
 memory

Signed-off-by: Lucas De Marchi 
Reviewed-by: Christian König  # v1
---
include/linux/iosys-map.h | 45 +++
1 file changed, 36 insertions(+), 9 deletions(-)

diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index 4b8406ee8bc4..f59dd00ed202 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -6,6 +6,7 @@
#ifndef __IOSYS_MAP_H__
#define __IOSYS_MAP_H__

+#include 
#include 
#include 

@@ -333,6 +334,26 @@ static inline void iosys_map_memset(struct iosys_map *dst, 
size_t offset,
memset(dst->vaddr + offset, value, len);
}

+#ifdef CONFIG_64BIT
+#define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) 
\
+   u64: val_ = readq(vaddr_iomem_)
+#else
+#define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) 
\
+   u64: memcpy_fromio(&(val_), vaddr_iomem__, sizeof(u64))


I tested io/sys and forgot again to test it for 32-bit :(. This
should fix the build for 32-bits:

diff --git a/include/linux/iosys-map.h b/include/linux/iosys-map.h
index 580e14cd360c..f8bc052f8975 100644
--- a/include/linux/iosys-map.h
+++ b/include/linux/iosys-map.h
@@ -341,7 +341,7 @@ static inline void iosys_map_memset(struct iosys_map *dst, 
size_t offset,
u64: writeq(val_, vaddr_iomem_)
 #else
 #define __iosys_map_rd_io_u64_case(val_, vaddr_iomem_) 
\
-   u64: memcpy_fromio(&(val_), vaddr_iomem__, sizeof(u64))
+   u64: memcpy_fromio(&(val_), vaddr_iomem_, sizeof(u64))
 #define __iosys_map_wr_io_u64_case(val_, vaddr_iomem_) \
u64: memcpy_toio(vaddr_iomem_, &(val_), sizeof(u64))
 #endif

Lucas De Marchi

Re: [PATCH v2 08/15] mfd: mt6370: Add Mediatek MT6370 support

Hi Lee,

Thanks for your helpful comments, we have some questions and replies below.

Lee Jones  於 2022年6月16日 週四 清晨6:49寫道：

>
> On Mon, 13 Jun 2022, ChiaEn Wu wrote:
>
> > From: ChiYuan Huang 
> >
> > Add Mediatek MT6370 MFD support.
> >
> > Signed-off-by: ChiYuan Huang 
> > ---
> >  drivers/mfd/Kconfig  |  13 ++
> >  drivers/mfd/Makefile |   1 +
> >  drivers/mfd/mt6370.c | 349 +++
> >  3 files changed, 363 insertions(+)
> >  create mode 100644 drivers/mfd/mt6370.c
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index 3b59456f5545..d9a7524a3e0e 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -937,6 +937,19 @@ config MFD_MT6360
> > PMIC part includes 2-channel BUCKs and 2-channel LDOs
> > LDO part includes 4-channel LDOs
> >
> > +config MFD_MT6370
> > + tristate "Mediatek MT6370 SubPMIC"
> > + select MFD_CORE
> > + select REGMAP_I2C
> > + select REGMAP_IRQ
> > + depends on I2C
> > + help
> > +   Say Y here to enable MT6370 SubPMIC functional support.
> > +   It integrate single cell battery charger with adc monitoring, RGB
>
> s/integrates/consists of a/
>
> "ADC"

We will fine it in the next patch.

>
> > +   LEDs, dual channel flashlight, WLED backlight driver, display bias
>
> > +   voltage supply, one general purpose LDO, and cc logic
> > +   controller with USBPD commmunication capable.
>
> The last part makes no sense - "and is USBPD"?

If we modify this help text to
"one general purpose LDO, and the USB Type-C & PD controller complies
with the latest USB Type-C and PD standards",
did these modifications meet your expectations?

>
> >  config MFD_MT6397
> >   tristate "MediaTek MT6397 PMIC Support"
> >   select MFD_CORE
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 858cacf659d6..62b27125420e 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -242,6 +242,7 @@ obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC)+= 
> > intel_soc_pmic_bxtwc.o
> >  obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC)   += intel_soc_pmic_chtwc.o
> >  obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)+= intel_soc_pmic_chtdc_ti.o
> >  obj-$(CONFIG_MFD_MT6360) += mt6360-core.o
> > +obj-$(CONFIG_MFD_MT6370) += mt6370.o
> >  mt6397-objs  := mt6397-core.o mt6397-irq.o mt6358-irq.o
> >  obj-$(CONFIG_MFD_MT6397) += mt6397.o
> >  obj-$(CONFIG_INTEL_SOC_PMIC_MRFLD)   += intel_soc_pmic_mrfld.o
> > diff --git a/drivers/mfd/mt6370.c b/drivers/mfd/mt6370.c
> > new file mode 100644
> > index ..6af9f73c9c0c
> > --- /dev/null
> > +++ b/drivers/mfd/mt6370.c
> > @@ -0,0 +1,349 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +enum {
> > + MT6370_USBC_I2C = 0,
> > + MT6370_PMU_I2C,
> > + MT6370_MAX_I2C
> > +};
> > +
> > +#define MT6370_REG_DEV_INFO  0x100
> > +#define MT6370_REG_CHG_IRQ1  0x1C0
> > +#define MT6370_REG_CHG_MASK1 0x1E0
> > +
> > +#define MT6370_VENID_MASKGENMASK(7, 4)
> > +
> > +#define MT6370_NUM_IRQREGS   16
> > +#define MT6370_USBC_I2CADDR  0x4E
> > +#define MT6370_REG_ADDRLEN   2
> > +#define MT6370_REG_MAXADDR   0x1FF
> > +
> > +/* IRQ definitions */
> > +#define MT6370_IRQ_DIRCHGON  0
> > +#define MT6370_IRQ_CHG_TREG  4
> > +#define MT6370_IRQ_CHG_AICR  5
> > +#define MT6370_IRQ_CHG_MIVR  6
> > +#define MT6370_IRQ_PWR_RDY   7
> > +#define MT6370_IRQ_FL_CHG_VINOVP 11
> > +#define MT6370_IRQ_CHG_VSYSUV12
> > +#define MT6370_IRQ_CHG_VSYSOV13
> > +#define MT6370_IRQ_CHG_VBATOV14
> > +#define MT6370_IRQ_CHG_VINOVPCHG 15
> > +#define MT6370_IRQ_TS_BAT_COLD   20
> > +#define MT6370_IRQ_TS_BAT_COOL   21
> > +#define MT6370_IRQ_TS_BAT_WARM   22
> > +#define MT6370_IRQ_TS_BAT_HOT23
> > +#define MT6370_IRQ_TS_STATC  24
> > +#define MT6370_IRQ_CHG_FAULT 25
> > +#define MT6370_IRQ_CHG_STATC 26
> > +#define MT6370_IRQ_CHG_TMR   27
> > +#define MT6370_IRQ_CHG_BATABS28
> > +#define MT6370_IRQ_CHG_ADPBAD29
> > +#define MT6370_IRQ_CHG_RVP   30
> > +#define MT6370_IRQ_TSHUTDOWN 31
> > +#define MT6370_IRQ_CHG_IINMEAS   32
> > +#define MT6370_IRQ_CHG_ICCMEAS   33
> > +#define MT6370_IRQ_CHGDET_DONE   34
> > +#define MT6370_IRQ_WDTMR 35
> > +#define MT6370_IRQ_SSFINISH  36
> > +#define MT6370_IRQ_CHG_RECHG 37
> > +#define MT6370_IRQ_CHG_TERM  38
> > +#define MT6370_IRQ_CHG_IEOC  39
> > +#define MT6370_IRQ_ADC_DONE  40
> > +#define MT6370_IRQ_PUMPX_DONE41
> > +#define MT6370_IRQ_BST_BATUV 45
> > +#define MT6370_IRQ_BST_MIDOV 46
> > +#define MT6370_IRQ_BST_OLP

Re: [PATCH v5 01/13] mm: add zone device coherent type memory support

2022-06-17 Thread Sierra Guiza, Alejandro (Alex)




On 6/17/2022 4:40 AM, David Hildenbrand wrote:

On 31.05.22 22:00, Alex Sierra wrote:

Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.

Signed-off-by: Alex Sierra 
Acked-by: Felix Kuehling 
Reviewed-by: Alistair Popple 
[hch: rebased ontop of the refcount changes,
   removed is_dev_private_or_coherent_page]
Signed-off-by: Christoph Hellwig 
---
  include/linux/memremap.h | 19 +++
  mm/memcontrol.c  |  7 ---
  mm/memory-failure.c  |  8 ++--
  mm/memremap.c| 10 ++
  mm/migrate_device.c  | 16 +++-
  mm/rmap.c|  5 +++--
  6 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 8af304f6b504..9f752ebed613 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -41,6 +41,13 @@ struct vmem_altmap {
   * A more complete discussion of unaddressable memory may be found in
   * include/linux/hmm.h and Documentation/vm/hmm.rst.
   *
+ * MEMORY_DEVICE_COHERENT:
+ * Device memory that is cache coherent from device and CPU point of view. This
+ * is used on platforms that have an advanced system bus (like CAPI or CXL). A
+ * driver can hotplug the device memory using ZONE_DEVICE and with that memory
+ * type. Any page of a process can be migrated to such memory. However no one

Any page might not be right, I'm pretty sure. ... just thinking about special 
pages
like vdso, shared zeropage, ... pinned pages ...


Hi David,

Yes, I think you're right. This type does not cover all special pages.  
I need to correct that on the cover letter.

Pinned pages are allowed as long as they're not long term pinned.

Regards,
Alex Sierra




+ * should be allowed to pin such memory so that it can always be evicted.
+ *
   * MEMORY_DEVICE_FS_DAX:
   * Host memory that has similar access semantics as System RAM i.e. DMA
   * coherent and supports page pinning. In support of coordinating page
@@ -61,6 +68,7 @@ struct vmem_altmap {
  enum memory_type {
/* 0 is reserved to catch uninitialized type fields */
MEMORY_DEVICE_PRIVATE = 1,
+   MEMORY_DEVICE_COHERENT,
MEMORY_DEVICE_FS_DAX,
MEMORY_DEVICE_GENERIC,
MEMORY_DEVICE_PCI_P2PDMA,
@@ -143,6 +151,17 @@ static inline bool folio_is_device_private(const struct 
folio *folio)

In general, this LGTM, and it should be correct with PageAnonExclusive I think.


However, where exactly is pinning forbidden?


Long-term pinning is forbidden since it would interfere with the device 
memory manager owning the
device-coherent pages (e.g. evictions in TTM). However, normal pinning 
is allowed on this device type.


Regards,
Alex Sierra

Re: [PATCH v5 01/13] mm: add zone device coherent type memory support

On 17.06.22 19:20, Sierra Guiza, Alejandro (Alex) wrote:
> 
> On 6/17/2022 4:40 AM, David Hildenbrand wrote:
>> On 31.05.22 22:00, Alex Sierra wrote:
>>> Device memory that is cache coherent from device and CPU point of view.
>>> This is used on platforms that have an advanced system bus (like CAPI
>>> or CXL). Any page of a process can be migrated to such memory. However,
>>> no one should be allowed to pin such memory so that it can always be
>>> evicted.
>>>
>>> Signed-off-by: Alex Sierra 
>>> Acked-by: Felix Kuehling 
>>> Reviewed-by: Alistair Popple 
>>> [hch: rebased ontop of the refcount changes,
>>>removed is_dev_private_or_coherent_page]
>>> Signed-off-by: Christoph Hellwig 
>>> ---
>>>   include/linux/memremap.h | 19 +++
>>>   mm/memcontrol.c  |  7 ---
>>>   mm/memory-failure.c  |  8 ++--
>>>   mm/memremap.c| 10 ++
>>>   mm/migrate_device.c  | 16 +++-
>>>   mm/rmap.c|  5 +++--
>>>   6 files changed, 49 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
>>> index 8af304f6b504..9f752ebed613 100644
>>> --- a/include/linux/memremap.h
>>> +++ b/include/linux/memremap.h
>>> @@ -41,6 +41,13 @@ struct vmem_altmap {
>>>* A more complete discussion of unaddressable memory may be found in
>>>* include/linux/hmm.h and Documentation/vm/hmm.rst.
>>>*
>>> + * MEMORY_DEVICE_COHERENT:
>>> + * Device memory that is cache coherent from device and CPU point of view. 
>>> This
>>> + * is used on platforms that have an advanced system bus (like CAPI or 
>>> CXL). A
>>> + * driver can hotplug the device memory using ZONE_DEVICE and with that 
>>> memory
>>> + * type. Any page of a process can be migrated to such memory. However no 
>>> one
>> Any page might not be right, I'm pretty sure. ... just thinking about 
>> special pages
>> like vdso, shared zeropage, ... pinned pages ...
> 

Well, you cannot migrate long term pages, that's what I meant :)

>>
>>> + * should be allowed to pin such memory so that it can always be evicted.
>>> + *
>>>* MEMORY_DEVICE_FS_DAX:
>>>* Host memory that has similar access semantics as System RAM i.e. DMA
>>>* coherent and supports page pinning. In support of coordinating page
>>> @@ -61,6 +68,7 @@ struct vmem_altmap {
>>>   enum memory_type {
>>> /* 0 is reserved to catch uninitialized type fields */
>>> MEMORY_DEVICE_PRIVATE = 1,
>>> +   MEMORY_DEVICE_COHERENT,
>>> MEMORY_DEVICE_FS_DAX,
>>> MEMORY_DEVICE_GENERIC,
>>> MEMORY_DEVICE_PCI_P2PDMA,
>>> @@ -143,6 +151,17 @@ static inline bool folio_is_device_private(const 
>>> struct folio *folio)
>> In general, this LGTM, and it should be correct with PageAnonExclusive I 
>> think.
>>
>>
>> However, where exactly is pinning forbidden?
> 
> Long-term pinning is forbidden since it would interfere with the device 
> memory manager owning the
> device-coherent pages (e.g. evictions in TTM). However, normal pinning 
> is allowed on this device type.

I don't see updates to folio_is_pinnable() in this patch.

So wouldn't try_grab_folio() simply pin these pages? What am I missing?

-- 
Thanks,

David / dhildenb

Re: [PATCH v8 2/2] drm/msm/dp: clean up pixel_rate from dp_ctrl.c

2022-06-17 Thread kernel test robot

Hi Kuogee,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on drm-exynos/exynos-drm-next]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next 
airlied/drm-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/intel-lab-lkp/linux/commits/Kuogee-Hsieh/force-link-training-for-display-resolution-change/20220617-00
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: hexagon-allmodconfig 
(https://download.01.org/0day-ci/archive/20220617/202206172356.j5cb8zdf-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
f0e608de27b3d56846eebf3712ab542979d6)
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/intel-lab-lkp/linux/commit/b04f0b39a03a9fc3728e9414157f9d5f0b8b2366
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Kuogee-Hsieh/force-link-training-for-display-resolution-change/20220617-00
git checkout b04f0b39a03a9fc3728e9414157f9d5f0b8b2366
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/gpu/drm/msm/

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

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/msm/dp/dp_ctrl.c:1587:5: warning: no previous prototype for 
>> function 'dp_ctrl_on_stream_phy_test_report' [-Wmissing-prototypes]
   int dp_ctrl_on_stream_phy_test_report(struct dp_ctrl *dp_ctrl)
   ^
   drivers/gpu/drm/msm/dp/dp_ctrl.c:1587:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
   int dp_ctrl_on_stream_phy_test_report(struct dp_ctrl *dp_ctrl)
   ^
   static 
   1 warning generated.


vim +/dp_ctrl_on_stream_phy_test_report +1587 drivers/gpu/drm/msm/dp/dp_ctrl.c

  1586  
> 1587  int dp_ctrl_on_stream_phy_test_report(struct dp_ctrl *dp_ctrl)
  1588  {
  1589  int ret = 0;
  1590  struct dp_ctrl_private *ctrl;
  1591  unsigned long pixel_rate;
  1592  
  1593  ctrl = container_of(dp_ctrl, struct dp_ctrl_private, dp_ctrl);
  1594  
  1595  pixel_rate = ctrl->panel->dp_mode.drm_mode.clock;
  1596  ret = dp_ctrl_enable_stream_clocks(ctrl, pixel_rate);
  1597  if (ret) {
  1598  DRM_ERROR("Failed to start pixel clocks. ret=%d\n", 
ret);
  1599  return ret;
  1600  }
  1601  
  1602  dp_ctrl_send_phy_test_pattern(ctrl);
  1603  
  1604  return 0;
  1605  }
  1606  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

Re: [PATCH v2 2/2] drm/i915/gt: Cleanup interface for MCR operations

2022-06-17 Thread Harish Chegondi

On Tue, Jun 14, 2022 at 05:10:19PM -0700, Matt Roper wrote:
> Let's replace the assortment of intel_gt_* and intel_uncore_* functions
> that operate on MCR registers with a cleaner set of interfaces:
> 
>   * intel_gt_mcr_read -- unicast read from specific instance
>   * intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated
> instance
>   * intel_gt_mcr_unicast_write -- unicast write to specific instance
>   * intel_gt_mcr_multicast_write[_fw] -- multicast write to all instances
> 
> We'll also replace the historic "slice" and "subslice" terminology with
> "group" and "instance" to match the documentation for more recent
> platforms; these days MCR steering applies to more types of replication
> than just slice/subslice.
> 
> v2:
>  - Reference the new kerneldoc from i915.rst.  (Jani)
>  - Tweak the wording of the documentation for a couple functions to
>clarify the difference between "_fw" and non-"_fw" forms.
> 
> Signed-off-by: Matt Roper 
> Acked-by: Jani Nikula 
> ---
>  Documentation/gpu/i915.rst  |  12 +
>  drivers/gpu/drm/i915/gem/i915_gem_stolen.c  |   2 +-
>  drivers/gpu/drm/i915/gt/intel_engine_cs.c   |  33 ++-
>  drivers/gpu/drm/i915/gt/intel_gt_debugfs.c  |   2 +-
>  drivers/gpu/drm/i915/gt/intel_gt_mcr.c  | 239 
>  drivers/gpu/drm/i915/gt/intel_gt_mcr.h  |  43 ++--
>  drivers/gpu/drm/i915/gt/intel_region_lmem.c |   4 +-
>  drivers/gpu/drm/i915/gt/intel_workarounds.c |   8 +-
>  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  |   2 +-
>  9 files changed, 200 insertions(+), 145 deletions(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 54060cd6c419..4e59db1cfb00 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -246,6 +246,18 @@ Display State Buffer
>  .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dsb.c
> :internal:
>  
> +GT Programming
> +==
> +
> +Multicast/Replicated (MCR) Registers
> +
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +   :doc: GT Multicast/Replicated (MCR) Register Support
> +
> +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c
> +   :internal:
> +
>  Memory Management and Command Submission
>  
>  
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index da30503d3ca2..fa54823d1219 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -835,7 +835,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, 
> u16 type,
>   } else {
>   resource_size_t lmem_range;
>  
> - lmem_range = intel_gt_read_register(&i915->gt0, 
> XEHPSDV_TILE0_ADDR_RANGE) & 0x;
> + lmem_range = intel_gt_mcr_read_any(&i915->gt0, 
> XEHPSDV_TILE0_ADDR_RANGE) & 0x;
>   lmem_size = lmem_range >> XEHPSDV_TILE_LMEM_RANGE_SHIFT;
>   lmem_size *= SZ_1G;
>   }
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 244af1bdb7db..136cc44c3deb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1428,14 +1428,6 @@ void intel_engine_cancel_stop_cs(struct 
> intel_engine_cs *engine)
>   ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
>  }
>  
> -static u32
> -read_subslice_reg(const struct intel_engine_cs *engine,
> -   int slice, int subslice, i915_reg_t reg)
> -{
> - return intel_uncore_read_with_mcr_steering(engine->uncore, reg,
> -slice, subslice);
> -}
> -
>  /* NB: please notice the memset */
>  void intel_engine_get_instdone(const struct intel_engine_cs *engine,
>  struct intel_instdone *instdone)
> @@ -1469,28 +1461,33 @@ void intel_engine_get_instdone(const struct 
> intel_engine_cs *engine,
>   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
>   for_each_instdone_gslice_dss_xehp(i915, sseu, iter, 
> slice, subslice) {
>   instdone->sampler[slice][subslice] =
> - read_subslice_reg(engine, slice, 
> subslice,
> -   
> GEN7_SAMPLER_INSTDONE);
> + intel_gt_mcr_read(engine->gt,
> +   GEN7_SAMPLER_INSTDONE,
> +   slice, subslice);
>   instdone->row[slice][subslice] =
> - read_subslice_reg(engine, slice, 
> subslice,
> -   GEN7_ROW_INSTDONE);
> + intel_gt_mcr_read(engine->gt,
> +

[PATCH v3 1/3] drm/msm/mdp4: convert to drm_crtc_handle_vblank()

Stop using deprecated drm_handle_vblank(), use drm_crtc_handle_vblank()
instead.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c
index 4d49f3ba6a96..ddcdd5e87853 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c
@@ -69,8 +69,7 @@ irqreturn_t mdp4_irq(struct msm_kms *kms)
struct mdp_kms *mdp_kms = to_mdp_kms(kms);
struct mdp4_kms *mdp4_kms = to_mdp4_kms(mdp_kms);
struct drm_device *dev = mdp4_kms->dev;
-   struct msm_drm_private *priv = dev->dev_private;
-   unsigned int id;
+   struct drm_crtc *crtc;
uint32_t status, enable;
 
enable = mdp4_read(mdp4_kms, REG_MDP4_INTR_ENABLE);
@@ -81,9 +80,9 @@ irqreturn_t mdp4_irq(struct msm_kms *kms)
 
mdp_dispatch_irqs(mdp_kms, status);
 
-   for (id = 0; id < priv->num_crtcs; id++)
-   if (status & mdp4_crtc_vblank(priv->crtcs[id]))
-   drm_handle_vblank(dev, id);
+   drm_for_each_crtc(crtc, dev)
+   if (status & mdp4_crtc_vblank(crtc))
+   drm_crtc_handle_vblank(crtc);
 
return IRQ_HANDLED;
 }
-- 
2.35.1

[PATCH v3 2/3] drm/msm/mdp5: convert to drm_crtc_handle_vblank()

Stop using deprecated drm_handle_vblank(), use drm_crtc_handle_vblank()
instead.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c
index 9b4c8d92ff32..43443a435d59 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c
@@ -82,8 +82,7 @@ irqreturn_t mdp5_irq(struct msm_kms *kms)
struct mdp_kms *mdp_kms = to_mdp_kms(kms);
struct mdp5_kms *mdp5_kms = to_mdp5_kms(mdp_kms);
struct drm_device *dev = mdp5_kms->dev;
-   struct msm_drm_private *priv = dev->dev_private;
-   unsigned int id;
+   struct drm_crtc *crtc;
uint32_t status, enable;
 
enable = mdp5_read(mdp5_kms, REG_MDP5_INTR_EN);
@@ -94,9 +93,9 @@ irqreturn_t mdp5_irq(struct msm_kms *kms)
 
mdp_dispatch_irqs(mdp_kms, status);
 
-   for (id = 0; id < priv->num_crtcs; id++)
-   if (status & mdp5_crtc_vblank(priv->crtcs[id]))
-   drm_handle_vblank(dev, id);
+   drm_for_each_crtc(crtc, dev)
+   if (status & mdp5_crtc_vblank(crtc))
+   drm_crtc_handle_vblank(crtc);
 
return IRQ_HANDLED;
 }
-- 
2.35.1

[PATCH v3 3/3] drm/msm: stop storing the array of CRTCs in struct msm_drm_private

Handling the array of CRTC duplicate the struct msm_drm_private
duplicates a list of CRTCs in the drm_device. Drop it and use the
existing list for CRTC enumeration.

Reported-by: kernel test robot 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c |  2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c| 29 
 drivers/gpu/drm/msm/msm_drv.h|  3 +--
 5 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e23e2552e802..e79f0a8817ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -806,7 +806,7 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
ret = PTR_ERR(crtc);
return ret;
}
-   priv->crtcs[priv->num_crtcs++] = crtc;
+   priv->num_crtcs++;
}
 
/* All CRTCs are compatible with all encoders */
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index fb48c8c19ec3..7449c1693e45 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -337,7 +337,7 @@ static int modeset_init(struct mdp4_kms *mdp4_kms)
goto fail;
}
 
-   priv->crtcs[priv->num_crtcs++] = crtc;
+   priv->num_crtcs++;
}
 
/*
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 3d5621a68f85..36808990f840 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -497,7 +497,7 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
DRM_DEV_ERROR(dev->dev, "failed to construct crtc %d 
(%d)\n", i, ret);
goto fail;
}
-   priv->crtcs[priv->num_crtcs++] = crtc;
+   priv->num_crtcs++;
}
 
/*
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 44485363f37a..29e508f69e19 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -149,7 +149,7 @@ static void msm_irq_uninstall(struct drm_device *dev)
 
 struct msm_vblank_work {
struct work_struct work;
-   int crtc_id;
+   struct drm_crtc *crtc;
bool enable;
struct msm_drm_private *priv;
 };
@@ -162,15 +162,15 @@ static void vblank_ctrl_worker(struct work_struct *work)
struct msm_kms *kms = priv->kms;
 
if (vbl_work->enable)
-   kms->funcs->enable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
+   kms->funcs->enable_vblank(kms, vbl_work->crtc);
else
-   kms->funcs->disable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
+   kms->funcs->disable_vblank(kms, vbl_work->crtc);
 
kfree(vbl_work);
 }
 
 static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
-   int crtc_id, bool enable)
+   struct drm_crtc *crtc, bool enable)
 {
struct msm_vblank_work *vbl_work;
 
@@ -180,7 +180,7 @@ static int vblank_ctrl_queue_work(struct msm_drm_private 
*priv,
 
INIT_WORK(&vbl_work->work, vblank_ctrl_worker);
 
-   vbl_work->crtc_id = crtc_id;
+   vbl_work->crtc = crtc;
vbl_work->enable = enable;
vbl_work->priv = priv;
 
@@ -354,6 +354,7 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
struct msm_drm_private *priv = dev_get_drvdata(dev);
struct drm_device *ddev;
struct msm_kms *kms;
+   struct drm_crtc *crtc;
int ret, i;
 
if (drm_firmware_drivers_only())
@@ -427,12 +428,14 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
ddev->mode_config.funcs = &mode_config_funcs;
ddev->mode_config.helper_private = &mode_config_helper_funcs;
 
-   for (i = 0; i < priv->num_crtcs; i++) {
+   drm_for_each_crtc(crtc, ddev) {
+   i = drm_crtc_index(crtc);
+
/* initialize event thread */
-   priv->event_thread[i].crtc_id = priv->crtcs[i]->base.id;
+   priv->event_thread[i].crtc = crtc;
priv->event_thread[i].dev = ddev;
priv->event_thread[i].worker = kthread_create_worker(0,
-   "crtc_event:%d", priv->event_thread[i].crtc_id);
+   "crtc_event:%d", priv->event_thread[i].crtc->base.id);
if (IS_ERR(priv->event_thread[i].worker)) {
ret = PTR_ERR(priv->event_thread[i].worker);
DRM_DEV_ERROR(dev, "failed to create crtc_event 
kthread\n");
@@ -563,25 +566,23 @@ static void msm_postclose(stru

[PATCH v4 0/3] drm/msm: convet to drm_crtc_handle_vblank()

This patchseries replaces drm_handle_vblank() with
drm_crtc_handle_vblank(). As a bonus result of this conversion it is
possible to drop the stored array of allocated CRTCs and use the core
CRTC iterators.

Changes since v3:
 - In msm_drm_init simplify the code by using an interim var for the
   event thread itself rather than just the index (suggested by Abhinav)

Changes since v2;
 - none (sent by mistake)

Changes since v1;
 - fixed uninitialized var access (LTP Robot)

Dmitry Baryshkov (3):
  drm/msm/mdp4: convert to drm_crtc_handle_vblank()
  drm/msm/mdp5: convert to drm_crtc_handle_vblank()
  drm/msm: stop storing the array of CRTCs in struct msm_drm_private

 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c |  9 +++--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c |  2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c |  9 +++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c| 44 +---
 drivers/gpu/drm/msm/msm_drv.h|  3 +-
 7 files changed, 35 insertions(+), 36 deletions(-)

-- 
2.35.1

[PATCH v4 1/3] drm/msm/mdp4: convert to drm_crtc_handle_vblank()

Stop using deprecated drm_handle_vblank(), use drm_crtc_handle_vblank()
instead.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c
index 4d49f3ba6a96..ddcdd5e87853 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c
@@ -69,8 +69,7 @@ irqreturn_t mdp4_irq(struct msm_kms *kms)
struct mdp_kms *mdp_kms = to_mdp_kms(kms);
struct mdp4_kms *mdp4_kms = to_mdp4_kms(mdp_kms);
struct drm_device *dev = mdp4_kms->dev;
-   struct msm_drm_private *priv = dev->dev_private;
-   unsigned int id;
+   struct drm_crtc *crtc;
uint32_t status, enable;
 
enable = mdp4_read(mdp4_kms, REG_MDP4_INTR_ENABLE);
@@ -81,9 +80,9 @@ irqreturn_t mdp4_irq(struct msm_kms *kms)
 
mdp_dispatch_irqs(mdp_kms, status);
 
-   for (id = 0; id < priv->num_crtcs; id++)
-   if (status & mdp4_crtc_vblank(priv->crtcs[id]))
-   drm_handle_vblank(dev, id);
+   drm_for_each_crtc(crtc, dev)
+   if (status & mdp4_crtc_vblank(crtc))
+   drm_crtc_handle_vblank(crtc);
 
return IRQ_HANDLED;
 }
-- 
2.35.1

[PATCH v4 3/3] drm/msm: stop storing the array of CRTCs in struct msm_drm_private

Handling the array of CRTC duplicate the struct msm_drm_private
duplicates a list of CRTCs in the drm_device. Drop it and use the
existing list for CRTC enumeration.

Reported-by: kernel test robot 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c |  2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c| 44 +---
 drivers/gpu/drm/msm/msm_drv.h|  3 +-
 5 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index e23e2552e802..e79f0a8817ac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -806,7 +806,7 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
ret = PTR_ERR(crtc);
return ret;
}
-   priv->crtcs[priv->num_crtcs++] = crtc;
+   priv->num_crtcs++;
}
 
/* All CRTCs are compatible with all encoders */
diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index fb48c8c19ec3..7449c1693e45 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -337,7 +337,7 @@ static int modeset_init(struct mdp4_kms *mdp4_kms)
goto fail;
}
 
-   priv->crtcs[priv->num_crtcs++] = crtc;
+   priv->num_crtcs++;
}
 
/*
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 3d5621a68f85..36808990f840 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -497,7 +497,7 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
DRM_DEV_ERROR(dev->dev, "failed to construct crtc %d 
(%d)\n", i, ret);
goto fail;
}
-   priv->crtcs[priv->num_crtcs++] = crtc;
+   priv->num_crtcs++;
}
 
/*
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 44485363f37a..567e77dae43b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -149,7 +149,7 @@ static void msm_irq_uninstall(struct drm_device *dev)
 
 struct msm_vblank_work {
struct work_struct work;
-   int crtc_id;
+   struct drm_crtc *crtc;
bool enable;
struct msm_drm_private *priv;
 };
@@ -162,15 +162,15 @@ static void vblank_ctrl_worker(struct work_struct *work)
struct msm_kms *kms = priv->kms;
 
if (vbl_work->enable)
-   kms->funcs->enable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
+   kms->funcs->enable_vblank(kms, vbl_work->crtc);
else
-   kms->funcs->disable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
+   kms->funcs->disable_vblank(kms, vbl_work->crtc);
 
kfree(vbl_work);
 }
 
 static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
-   int crtc_id, bool enable)
+   struct drm_crtc *crtc, bool enable)
 {
struct msm_vblank_work *vbl_work;
 
@@ -180,7 +180,7 @@ static int vblank_ctrl_queue_work(struct msm_drm_private 
*priv,
 
INIT_WORK(&vbl_work->work, vblank_ctrl_worker);
 
-   vbl_work->crtc_id = crtc_id;
+   vbl_work->crtc = crtc;
vbl_work->enable = enable;
vbl_work->priv = priv;
 
@@ -354,7 +354,8 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
struct msm_drm_private *priv = dev_get_drvdata(dev);
struct drm_device *ddev;
struct msm_kms *kms;
-   int ret, i;
+   struct drm_crtc *crtc;
+   int ret;
 
if (drm_firmware_drivers_only())
return -ENODEV;
@@ -427,20 +428,23 @@ static int msm_drm_init(struct device *dev, const struct 
drm_driver *drv)
ddev->mode_config.funcs = &mode_config_funcs;
ddev->mode_config.helper_private = &mode_config_helper_funcs;
 
-   for (i = 0; i < priv->num_crtcs; i++) {
+   drm_for_each_crtc(crtc, ddev) {
+   struct msm_drm_thread *ev_thread;
+
/* initialize event thread */
-   priv->event_thread[i].crtc_id = priv->crtcs[i]->base.id;
-   priv->event_thread[i].dev = ddev;
-   priv->event_thread[i].worker = kthread_create_worker(0,
-   "crtc_event:%d", priv->event_thread[i].crtc_id);
-   if (IS_ERR(priv->event_thread[i].worker)) {
-   ret = PTR_ERR(priv->event_thread[i].worker);
+   ev_thread = &priv->event_thread[drm_crtc_index(crtc)];
+   ev_thread->crtc = crtc;
+   ev_thread->dev = ddev;
+   ev_thread->worker = kthread_create_worker(0,
+

[PATCH v4 2/3] drm/msm/mdp5: convert to drm_crtc_handle_vblank()

Stop using deprecated drm_handle_vblank(), use drm_crtc_handle_vblank()
instead.

Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c
index 9b4c8d92ff32..43443a435d59 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c
@@ -82,8 +82,7 @@ irqreturn_t mdp5_irq(struct msm_kms *kms)
struct mdp_kms *mdp_kms = to_mdp_kms(kms);
struct mdp5_kms *mdp5_kms = to_mdp5_kms(mdp_kms);
struct drm_device *dev = mdp5_kms->dev;
-   struct msm_drm_private *priv = dev->dev_private;
-   unsigned int id;
+   struct drm_crtc *crtc;
uint32_t status, enable;
 
enable = mdp5_read(mdp5_kms, REG_MDP5_INTR_EN);
@@ -94,9 +93,9 @@ irqreturn_t mdp5_irq(struct msm_kms *kms)
 
mdp_dispatch_irqs(mdp_kms, status);
 
-   for (id = 0; id < priv->num_crtcs; id++)
-   if (status & mdp5_crtc_vblank(priv->crtcs[id]))
-   drm_handle_vblank(dev, id);
+   drm_for_each_crtc(crtc, dev)
+   if (status & mdp5_crtc_vblank(crtc))
+   drm_crtc_handle_vblank(crtc);
 
return IRQ_HANDLED;
 }
-- 
2.35.1

Re: [PATCH] drm/msm/dpu: limit wb modes based on max_mixer_width


On 16/06/2022 22:26, Abhinav Kumar wrote:

As explained in [1], using max_linewidth to limit the modes
does not seem to remove 4K modes on chipsets such as
sm8250 where the max_linewidth actually supports 4k.

This would have been alright if dual SSPP support was
present but otherwise fails the per SSPP bandwidth check.

The ideal way to implement this would be to filter out
the modes which will exceed the bandwidth check by computing
it.

But this would be an exhaustive solution till we have
dual SSPP support.

Let's instead use max_mixer_width to limit the modes.

max_mixer_width still remains 2560 on sm8250 so even if
the max_linewidth is 4096, the only way 4k modes could have
been supported is to have source split enabled on the SSPP.

Since source split support is not enabled yet in DPU driver,
enforce max_mixer_width as the upper limit on the modes.

[1] https://patchwork.freedesktop.org/patch/489662/

Fixes: e67dcecda06f ("drm/msm/dpu: limit writeback modes according to 
max_linewidth")
Signed-off-by: Abhinav Kumar 


Reviewed-by: Dmitry Baryshkov 


--
With best wishes
Dmitry

[PATCH v6 00/10] drm/i915: ttm for stolen

This series refactors i915's stolen memory region to use ttm.

v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes 
testing
dmesg warning regressions.

v3: rebase to latest drm-tip.
fix v2 code refactor which could leave a buffer pinned.
locally passes fftl again now.

v4: - Allow memory regions creators to do allocation. Allows stolen region 
to track
  it's own reservations.
- Pre-reserve first page of stolen mem (add back 
WaSkipStolenMemoryFirstPage:bdw+)
- Improve commit descritpion for "drm/i915: sanitize mem_flags for 
stolen buffers"
- replace i915_gem_object_pin_pages_unlocked() call with manual locking 
and pinning.
  this avoids ww ctx class reuse during context creation -> ring vma 
obj alloc.

v5: - detect both types of stolen as stolen buffers in
  "drm/i915: sanitize mem_flags for stolen buffers"
- in stolen_object_init limit page size to mem region minimum.
  The range allocator expects the page_size to define the
  alignment

v6: - Share first 4 patches from ttm for internal series as generic
  i915 ttm fixes
- Drop patch 4 from v5. We don't need separate object ops just
  to satisfy test interfaces. The tests have now been fixed via
  checking whether the memory region is private to decide
  whether to mmap
- Add new buffer pin alloc flag to allow creation of buffers in
  their final ttm placement instead of deferring until
  get_pages. This fixes legacy fallback paths for buffer
  allocations during stolen memory pressure.

Robert Beckett (10):
  drm/i915/ttm: dont trample cache_level overrides during ttm move
  drm/i915: limit ttm to dma32 for i965G[M]
  drm/i915/ttm: only trust snooping for dgfx when deciding default
cache_level
  drm/i915/gem: selftest should not attempt mmap of private regions
  drm/i915: instantiate ttm ranger manager for stolen memory
  drm/i915: sanitize mem_flags for stolen buffers
  drm/i915: ttm move/clear logic fix
  drm/i915: allow memory region creators to alloc and free the region
  drm/i915/ttm: add buffer pin on alloc flag
  drm/i915: stolen memory use ttm backend

 drivers/gpu/drm/i915/display/intel_fbc.c  |  78 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  16 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 440 +++---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  29 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   7 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  47 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|   3 +
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   4 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  16 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |   5 -
 drivers/gpu/drm/i915/intel_memory_region.c|  16 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   2 +
 drivers/gpu/drm/i915/intel_region_ttm.c   |  80 +++-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |   3 +-
 18 files changed, 414 insertions(+), 369 deletions(-)

-- 
2.25.1

[PATCH v6 01/10] drm/i915/ttm: dont trample cache_level overrides during ttm move

Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.

TTM movement code came along and decided that it could make that
decision at that time, which is usually well after object creation, so
overrode the cache_level decision and reverted it back to its default
decision.

Add logic to indicate whether the caching mode has been set by anything
other than the move logic. If so, assume that the code that overrode the
defaults knows best and keep it.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 ++---
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 06b1b188ce5a..519887769c08 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -125,6 +125,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
 
obj->cache_level = cache_level;
+   obj->ttm.cache_level_override = true;
 
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 2c88bdb8ff7c..6632ed52e919 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -605,6 +605,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
+   bool cache_level_override:1;
} ttm;
 
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..27d59639177f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1241,6 +1241,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_gem_object_init_memory_region(obj, mem);
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
+   obj->ttm.cache_level_override = false;
i915_gem_object_unlock(obj);
 
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a10716f4e717..4c1de0b4a10f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -123,9 +123,12 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
I915_BO_FLAG_STRUCT_PAGE;
 
-   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
-  bo->ttm);
-   i915_gem_object_set_cache_coherency(obj, cache_level);
+   if (!obj->ttm.cache_level_override) {
+   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
+  bo->resource, bo->ttm);
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+   obj->ttm.cache_level_override = false;
+   }
 }
 
 /**
-- 
2.25.1

[PATCH v6 03/10] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level

By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 4c1de0b4a10f..40249fa28a7a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -46,7 +46,9 @@ static enum i915_cache_level
 i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
 struct ttm_tt *ttm)
 {
-   return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+   bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+   return ((HAS_LLC(i915) || can_snoop) &&
!i915_ttm_gtt_binds_lmem(res) &&
ttm->caching == ttm_cached) ? I915_CACHE_LLC :
I915_CACHE_NONE;
-- 
2.25.1

[PATCH v6 04/10] drm/i915/gem: selftest should not attempt mmap of private regions

During testing make can_mmap consider whether the region is private.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 5bc93a1ce3e3..76181e28c75e 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -869,6 +869,9 @@ static bool can_mmap(struct drm_i915_gem_object *obj, enum 
i915_mmap_type type)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
bool no_map;
 
+   if (obj->mm.region && obj->mm.region->private)
+   return false;
+
if (obj->ops->mmap_offset)
return type == I915_MMAP_TYPE_FIXED;
else if (type == I915_MMAP_TYPE_FIXED)
-- 
2.25.1

[PATCH v6 02/10] drm/i915: limit ttm to dma32 for i965G[M]

i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 62ff77445b01..fd2ecfdd8fa1 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -32,10 +32,15 @@
 int intel_region_ttm_device_init(struct drm_i915_private *dev_priv)
 {
struct drm_device *drm = &dev_priv->drm;
+   bool use_dma32 = false;
+
+   /* i965g[m] cannot relocate objects above 4GiB. */
+   if (IS_I965GM(dev_priv) || IS_I965G(dev_priv))
+   use_dma32 = true;
 
return ttm_device_init(&dev_priv->bdev, i915_ttm_driver(),
   drm->dev, drm->anon_inode->i_mapping,
-  drm->vma_offset_manager, false, false);
+  drm->vma_offset_manager, false, use_dma32);
 }
 
 /**
-- 
2.25.1

[PATCH v6 05/10] drm/i915: instantiate ttm ranger manager for stolen memory

prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c |  6 ++--
 drivers/gpu/drm/i915/intel_region_ttm.c  | 31 +++-
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 40249fa28a7a..675e9ab30396 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -60,11 +60,13 @@ i915_ttm_region(struct ttm_device *bdev, int ttm_mem_type)
struct drm_i915_private *i915 = container_of(bdev, typeof(*i915), bdev);
 
/* There's some room for optimization here... */
-   GEM_BUG_ON(ttm_mem_type != I915_PL_SYSTEM &&
-  ttm_mem_type < I915_PL_LMEM0);
+   GEM_BUG_ON(ttm_mem_type == I915_PL_GGTT);
+
if (ttm_mem_type == I915_PL_SYSTEM)
return intel_memory_region_lookup(i915, INTEL_MEMORY_SYSTEM,
  0);
+   if (ttm_mem_type == I915_PL_STOLEN)
+   return i915->mm.stolen_region;
 
return intel_memory_region_lookup(i915, INTEL_MEMORY_LOCAL,
  ttm_mem_type - I915_PL_LMEM0);
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index fd2ecfdd8fa1..694e9acb69e2 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -54,7 +54,7 @@ void intel_region_ttm_device_fini(struct drm_i915_private 
*dev_priv)
 
 /*
  * Map the i915 memory regions to TTM memory types. We use the
- * driver-private types for now, reserving TTM_PL_VRAM for stolen
+ * driver-private types for now, reserving I915_PL_STOLEN for stolen
  * memory and TTM_PL_TT for GGTT use if decided to implement this.
  */
 int intel_region_to_ttm_type(const struct intel_memory_region *mem)
@@ -63,11 +63,17 @@ int intel_region_to_ttm_type(const struct 
intel_memory_region *mem)
 
GEM_BUG_ON(mem->type != INTEL_MEMORY_LOCAL &&
   mem->type != INTEL_MEMORY_MOCK &&
-  mem->type != INTEL_MEMORY_SYSTEM);
+  mem->type != INTEL_MEMORY_SYSTEM &&
+  mem->type != INTEL_MEMORY_STOLEN_SYSTEM &&
+  mem->type != INTEL_MEMORY_STOLEN_LOCAL);
 
if (mem->type == INTEL_MEMORY_SYSTEM)
return TTM_PL_SYSTEM;
 
+   if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+   mem->type == INTEL_MEMORY_STOLEN_LOCAL)
+   return I915_PL_STOLEN;
+
type = mem->instance + TTM_PL_PRIV;
GEM_BUG_ON(type >= TTM_NUM_MEM_TYPES);
 
@@ -91,10 +97,16 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int mem_type = intel_region_to_ttm_type(mem);
int ret;
 
-   ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
- resource_size(&mem->region),
- mem->io_size,
- mem->min_page_size, PAGE_SIZE);
+   if (mem_type == I915_PL_STOLEN) {
+   ret = ttm_range_man_init(bdev, mem_type, false,
+resource_size(&mem->region) >> 
PAGE_SHIFT);
+   mem->is_range_manager = true;
+   } else {
+   ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
+ resource_size(&mem->region),
+ mem->io_size,
+ mem->min_page_size, PAGE_SIZE);
+   }
if (ret)
return ret;
 
@@ -114,6 +126,7 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
 int intel_region_ttm_fini(struct intel_memory_region *mem)
 {
struct ttm_resource_manager *man = mem->region_private;
+   int mem_type = intel_region_to_ttm_type(mem);
int ret = -EBUSY;
int count;
 
@@ -144,8 +157,10 @@ int intel_region_ttm_fini(struct intel_memory_region *mem)
if (ret || !man)
return ret;
 
-   ret = i915_ttm_buddy_man_fini(&mem->i915->bdev,
- intel_region_to_ttm_type(mem));
+   if (mem_type == I915_PL_STOLEN)
+   ret = ttm_range_man_fini(&mem->i915->bdev, mem_type);
+   else
+   ret = i915_ttm_buddy_man_fini(&mem->i915->bdev, mem_type);
GEM_WARN_ON(ret);
mem->region_private = NULL;
 
-- 
2.25.1

[PATCH v6 10/10] drm/i915: stolen memory use ttm backend

refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/display/intel_fbc.c  |  78 ++--
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 -
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 440 +++---
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   7 +
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   4 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  16 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |   5 -
 drivers/gpu/drm/i915/intel_region_ttm.c   |  42 +-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |   3 +-
 13 files changed, 294 insertions(+), 342 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 8b807284cde1..6f3afac5e8c9 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -38,6 +38,7 @@
  * forcibly disable it to allow proper screen updates.
  */
 
+#include "gem/i915_gem_stolen.h"
 #include 
 
 #include 
@@ -51,6 +52,7 @@
 #include "intel_display_types.h"
 #include "intel_fbc.h"
 #include "intel_frontbuffer.h"
+#include "gem/i915_gem_region.h"
 
 #define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS; 
(__fbc_id)++) \
@@ -92,8 +94,8 @@ struct intel_fbc {
struct mutex lock;
unsigned int busy_bits;
 
-   struct drm_mm_node compressed_fb;
-   struct drm_mm_node compressed_llb;
+   struct ttm_resource *compressed_fb;
+   struct ttm_resource *compressed_llb;
 
enum intel_fbc_id id;
 
@@ -331,16 +333,20 @@ static void i8xx_fbc_nuke(struct intel_fbc *fbc)
 static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
+   u64 llb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_llb);
 
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   GEM_BUG_ON(llb_offset == I915_BO_INVALID_OFFSET);
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_fb.start, U32_MAX));
+fb_offset, U32_MAX));
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_llb.start, U32_MAX));
+llb_offset, U32_MAX));
 
intel_de_write(i915, FBC_CFB_BASE,
-  i915->dsm.start + fbc->compressed_fb.start);
+  i915->dsm.start + fb_offset);
intel_de_write(i915, FBC_LL_BASE,
-  i915->dsm.start + fbc->compressed_llb.start);
+  i915->dsm.start + llb_offset);
 }
 
 static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -448,8 +454,10 @@ static bool g4x_fbc_is_compressing(struct intel_fbc *fbc)
 static void g4x_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
 
-   intel_de_write(i915, DPFC_CB_BASE, fbc->compressed_fb.start);
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   intel_de_write(i915, DPFC_CB_BASE, fb_offset);
 }
 
 static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -499,8 +507,10 @@ static bool ilk_fbc_is_compressing(struct intel_fbc *fbc)
 static void ilk_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
 
-   intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), 
fbc->compressed_fb.start);
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fb_offset);
 }
 
 static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -744,21 +754,24 @@ static int find_compression_limit(struct intel_fbc *fbc,
 {
struct drm_i915_private *i915 = fbc->i915;
u64 end = intel_fbc_stolen_end(i915);
-   int ret, limit = min_limit;
+   int limit = min_limit;
+   struct ttm_resource *res;
 
size /= limit;
 
/* Try to over-allocate to reduce reallocations and fragmentation. */
-   ret = i915_gem_stolen_insert_node_in_range(i915, &fbc->compressed_fb,
-  size <<= 1, 4096, 0, end);
-   if (ret == 0)
+   res = i915_gem_stolen_reserve_range(i915, size <<= 1, 0, end);
+   if (!IS_ERR(res)) {
+   fbc->compressed_fb = res;
return limit;
+   }
 
for (; limit <= in

[PATCH v6 09/10] drm/i915/ttm: add buffer pin on alloc flag

For situations where allocations need to fail on alloc instead of
delayed get_pages, add a new alloc flag to pin the ttm bo.
This makes sure that the resource has been allocated during buffer
creation, allowing it to fail with an error if the placement is
exhausted.
This allows existing fallback options for stolen backend allocation like
create_ring_vma to work as expected.

Signed-off-by: Robert Beckett 
---
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 13 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 25 ++-
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 6632ed52e919..07bc11247a3e 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -325,17 +325,20 @@ struct drm_i915_gem_object {
  * dealing with userspace objects the CPU fault handler is free to ignore this.
  */
 #define I915_BO_ALLOC_GPU_ONLY   BIT(6)
+/* object should be pinned in destination region from allocation */
+#define I915_BO_ALLOC_PINNED BIT(7)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
 I915_BO_ALLOC_PM_VOLATILE | \
 I915_BO_ALLOC_PM_EARLY | \
-I915_BO_ALLOC_GPU_ONLY)
-#define I915_BO_READONLY  BIT(7)
-#define I915_TILING_QUIRK_BIT 8 /* unknown swizzling; do not release! */
-#define I915_BO_PROTECTED BIT(9)
-#define I915_BO_WAS_BOUND_BIT 10
+I915_BO_ALLOC_GPU_ONLY | \
+I915_BO_ALLOC_PINNED)
+#define I915_BO_READONLY  BIT(8)
+#define I915_TILING_QUIRK_BIT 9 /* unknown swizzling; do not release! */
+#define I915_BO_PROTECTED BIT(10)
+#define I915_BO_WAS_BOUND_BIT 11
/**
 * @mem_flags - Mutable placement-related flags
 *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 27d59639177f..bb988608296d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -998,6 +998,13 @@ static void i915_ttm_delayed_free(struct 
drm_i915_gem_object *obj)
 {
GEM_BUG_ON(!obj->ttm.created);
 
+   /* stolen objects are pinned for lifetime. Unpin before putting */
+   if (obj->flags & I915_BO_ALLOC_PINNED) {
+   ttm_bo_reserve(i915_gem_to_ttm(obj), true, false, NULL);
+   ttm_bo_unpin(i915_gem_to_ttm(obj));
+   ttm_bo_unreserve(i915_gem_to_ttm(obj));
+   }
+
ttm_bo_put(i915_gem_to_ttm(obj));
 }
 
@@ -1193,6 +1200,9 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
.no_wait_gpu = false,
};
enum ttm_bo_type bo_type;
+   struct ttm_place _place;
+   struct ttm_placement _placement;
+   struct ttm_placement *placement;
int ret;
 
drm_gem_private_object_init(&i915->drm, &obj->base, size);
@@ -1222,6 +1232,17 @@ int __i915_gem_ttm_object_init(struct 
intel_memory_region *mem,
 */
i915_gem_object_make_unshrinkable(obj);
 
+   if (obj->flags & I915_BO_ALLOC_PINNED) {
+   i915_ttm_place_from_region(mem, &_place, obj->bo_offset,
+  obj->base.size, obj->flags);
+   _placement.num_placement = 1;
+   _placement.placement = &_place;
+   _placement.num_busy_placement = 0;
+   _placement.busy_placement = NULL;
+   placement = &_placement;
+   } else {
+   placement = &i915_sys_placement;
+   }
/*
 * If this function fails, it will call the destructor, but
 * our caller still owns the object. So no freeing in the
@@ -1230,7 +1251,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 * until successful initialization.
 */
ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), size,
-  bo_type, &i915_sys_placement,
+  bo_type, placement,
   page_size >> PAGE_SHIFT,
   &ctx, NULL, NULL, i915_ttm_bo_destroy);
if (ret)
@@ -1242,6 +1263,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
obj->ttm.cache_level_override = false;
+   if (obj->flags & I915_BO_ALLOC_PINNED)
+   ttm_bo_pin(i915_gem_to_ttm(obj));
i915_gem_object_unlock(obj);
 
return 0;
-- 
2.25.1

[PATCH v6 07/10] drm/i915: ttm move/clear logic fix

ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.

The desired behaviour is to clear user allocated buffers and any kernel
buffers that specifically requests it only.
Make the logic match the desired behaviour.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 22 +++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 81c67ca9edda..a3f8fc056dbc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,6 +3,7 @@
  * Copyright © 2021 Intel Corporation
  */
 
+#include "drm/ttm/ttm_tt.h"
 #include 
 
 #include "i915_deps.h"
@@ -476,6 +477,25 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
return fence;
 }
 
+static bool
+allow_clear(struct drm_i915_gem_object *obj, struct ttm_tt *ttm, struct 
ttm_resource *dst_mem)
+{
+   /* never clear stolen */
+   if (dst_mem->mem_type == I915_PL_STOLEN)
+   return false;
+   /*
+* we want to clear user buffers and any kernel buffers
+* that specifically request clearing.
+*/
+   if (obj->flags & I915_BO_ALLOC_USER)
+   return true;
+
+   if (ttm && ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)
+   return true;
+
+   return false;
+}
+
 /**
  * i915_ttm_move - The TTM move callback used by i915.
  * @bo: The buffer object.
@@ -526,7 +546,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
return PTR_ERR(dst_rsgt);
 
clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || 
!ttm_tt_is_populated(ttm));
-   if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+   if (!clear || allow_clear(obj, ttm, dst_mem)) {
struct i915_deps deps;
 
i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | 
__GFP_NOWARN);
-- 
2.25.1

[PATCH v6 06/10] drm/i915: sanitize mem_flags for stolen buffers