[PATCH] drm/imx/dcss: Use simple encoder

[Tian Tao]

The driver uses empty implementations for its encoders. Replace
the code with the generic simple encoder.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/imx/dcss/dcss-kms.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/imx/dcss/dcss-kms.c 
b/drivers/gpu/drm/imx/dcss/dcss-kms.c
index b549ce5e..5d7d228 100644
--- a/drivers/gpu/drm/imx/dcss/dcss-kms.c
+++ b/drivers/gpu/drm/imx/dcss/dcss-kms.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "dcss-dev.h"
@@ -59,10 +60,6 @@ static void dcss_kms_mode_config_init(struct dcss_kms_dev 
*kms)
config->helper_private = &dcss_mode_config_helpers;
 }
 
-static const struct drm_encoder_funcs dcss_kms_simple_encoder_funcs = {
-   .destroy = drm_encoder_cleanup,
-};
-
 static int dcss_kms_bridge_connector_init(struct dcss_kms_dev *kms)
 {
struct drm_device *ddev = &kms->base;
@@ -84,9 +81,8 @@ static int dcss_kms_bridge_connector_init(struct dcss_kms_dev 
*kms)
 
encoder->possible_crtcs = drm_crtc_mask(crtc);
 
-   ret = drm_encoder_init(&kms->base, encoder,
-  &dcss_kms_simple_encoder_funcs,
-  DRM_MODE_ENCODER_NONE, NULL);
+   ret = drm_simple_encoder_init(&kms->base, encoder,
+ DRM_MODE_ENCODER_NONE);
if (ret) {
dev_err(ddev->dev, "Failed initializing encoder %d.\n", ret);
return ret;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm: add simpledrm driver

[Thomas Zimmermann]

Hi

Am 10.03.21 um 03:50 schrieb nerdopolis:

On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote:

Hey

On request of Noralf, I picked up the patches and prepared v5. Works fine with
Xorg, if configured according to:
 https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html
If anyone knows how to make Xorg pick it up dynamically without such a static
configuration, please let me know.




Hi

I am kind of curious as I do have interest in seeing this merged as well.


Please take a look at [1]. It's not the same driver, but something to 
the same effect. I know it's been almost a year, but I do work on this 
and intend to come back with a new version during 2021.


I currently work on fastboot support for the new driver. But it's a 
complicated matter and takes time. If there's interest, we could talk 
about merging what's already there.


Best regards
Thomas

[1] 
https://lore.kernel.org/dri-devel/20200625120011.16168-1-tzimmerm...@suse.de/




There is an email in this thread from 2018, but when I tried to import an mbox
file from the whole month for August 2018, for some reason, kmail doesn't see
the sender and mailing list recipient in that one, so I will reply to this one,
because I was able to import this into my mail client.
https://www.spinics.net/lists/dri-devel/msg185519.html

I was able to get this to build against Linux 4.8, but not against a newer
version, some headers seem to have been split, and some things are off by 8
and other things. I could NOT find a git repo, but I was able to find the
newest patches I could find, and import those with git am against 4.8 with
some tweaks. If that is needed, I can link it, but only if you want.

However in QEMU I wasn't able to figure out how to make it create a
/dev/dri/card0 device, even after blacklisting the other modules for qxl,
cirrus, etc, and then modprobe-ing simpledrm

In my view something like this is would be useful. There still could be
hardware devices that don't have modesetting support (like vmvga in
qemu/virt-manager as an example). And most wayland servers need a
/dev/dri/card0 device as well as a potential user-mode TTY replacement would
also need /dev/dri/card0

I will admit I unfortunately failed to get it to build against master. I
couldn't figure out some of the changes, where some new structs were off by
a factor of 8.


Thanks



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] dt-bindings: leds: backlight: qcom-wled: Add PMI8994 compatible

[Lee Jones]

On Sun, 28 Feb 2021, Konrad Dybcio wrote:

> Document the newly added PMI8994 compatible.
> 
> Signed-off-by: Konrad Dybcio 

Applied, thanks.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/9] fs: rename alloc_anon_inode to alloc_anon_inode_sb

[Christian Brauner]

On Tue, Mar 09, 2021 at 04:53:40PM +0100, Christoph Hellwig wrote:
> Rename alloc_inode to free the name for a new variant that does not
> need boilerplate to create a super_block first.
> 
> Signed-off-by: Christoph Hellwig 
> ---

Looks good (with the metioned fix in
https://lore.kernel.org/lkml/20210310083040.ga5...@lst.de)

Reviewed-by: Christian Brauner 

>  arch/powerpc/platforms/pseries/cmm.c | 2 +-
>  drivers/dma-buf/dma-buf.c| 2 +-
>  drivers/gpu/drm/drm_drv.c| 2 +-
>  drivers/misc/cxl/api.c   | 2 +-
>  drivers/misc/vmw_balloon.c   | 2 +-
>  drivers/scsi/cxlflash/ocxl_hw.c  | 2 +-
>  drivers/virtio/virtio_balloon.c  | 2 +-
>  fs/aio.c | 2 +-
>  fs/anon_inodes.c | 4 ++--
>  fs/libfs.c   | 2 +-
>  include/linux/fs.h   | 2 +-
>  kernel/resource.c| 2 +-
>  mm/z3fold.c  | 2 +-
>  mm/zsmalloc.c| 2 +-
>  14 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/pseries/cmm.c 
> b/arch/powerpc/platforms/pseries/cmm.c
> index 45a3a3022a85c9..6d36b858b14df1 100644
> --- a/arch/powerpc/platforms/pseries/cmm.c
> +++ b/arch/powerpc/platforms/pseries/cmm.c
> @@ -580,7 +580,7 @@ static int cmm_balloon_compaction_init(void)
>   return rc;
>   }
>  
> - b_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
> + b_dev_info.inode = alloc_anon_inode_sb(balloon_mnt->mnt_sb);
>   if (IS_ERR(b_dev_info.inode)) {
>   rc = PTR_ERR(b_dev_info.inode);
>   b_dev_info.inode = NULL;
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f264b70c383eb4..dedcc9483352dc 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -445,7 +445,7 @@ static inline int is_dma_buf_file(struct file *file)
>  static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
>  {
>   struct file *file;
> - struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
> + struct inode *inode = alloc_anon_inode_sb(dma_buf_mnt->mnt_sb);
>  
>   if (IS_ERR(inode))
>   return ERR_CAST(inode);
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 20d22e41d7ce74..87e7214a8e3565 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -519,7 +519,7 @@ static struct inode *drm_fs_inode_new(void)
>   return ERR_PTR(r);
>   }
>  
> - inode = alloc_anon_inode(drm_fs_mnt->mnt_sb);
> + inode = alloc_anon_inode_sb(drm_fs_mnt->mnt_sb);
>   if (IS_ERR(inode))
>   simple_release_fs(&drm_fs_mnt, &drm_fs_cnt);
>  
> diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c
> index b493de962153ba..2efbf6c98028ef 100644
> --- a/drivers/misc/cxl/api.c
> +++ b/drivers/misc/cxl/api.c
> @@ -73,7 +73,7 @@ static struct file *cxl_getfile(const char *name,
>   goto err_module;
>   }
>  
> - inode = alloc_anon_inode(cxl_vfs_mount->mnt_sb);
> + inode = alloc_anon_inode_sb(cxl_vfs_mount->mnt_sb);
>   if (IS_ERR(inode)) {
>   file = ERR_CAST(inode);
>   goto err_fs;
> diff --git a/drivers/misc/vmw_balloon.c b/drivers/misc/vmw_balloon.c
> index b837e7eba5f7dc..5d057a05ddbee8 100644
> --- a/drivers/misc/vmw_balloon.c
> +++ b/drivers/misc/vmw_balloon.c
> @@ -1900,7 +1900,7 @@ static __init int vmballoon_compaction_init(struct 
> vmballoon *b)
>   return PTR_ERR(vmballoon_mnt);
>  
>   b->b_dev_info.migratepage = vmballoon_migratepage;
> - b->b_dev_info.inode = alloc_anon_inode(vmballoon_mnt->mnt_sb);
> + b->b_dev_info.inode = alloc_anon_inode_sb(vmballoon_mnt->mnt_sb);
>  
>   if (IS_ERR(b->b_dev_info.inode))
>   return PTR_ERR(b->b_dev_info.inode);
> diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
> index 244fc27215dc79..40184ed926b557 100644
> --- a/drivers/scsi/cxlflash/ocxl_hw.c
> +++ b/drivers/scsi/cxlflash/ocxl_hw.c
> @@ -88,7 +88,7 @@ static struct file *ocxlflash_getfile(struct device *dev, 
> const char *name,
>   goto err2;
>   }
>  
> - inode = alloc_anon_inode(ocxlflash_vfs_mount->mnt_sb);
> + inode = alloc_anon_inode_sb(ocxlflash_vfs_mount->mnt_sb);
>   if (IS_ERR(inode)) {
>   rc = PTR_ERR(inode);
>   dev_err(dev, "%s: alloc_anon_inode failed rc=%d\n",
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 8985fc2cea8615..cae76ee5bdd688 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -916,7 +916,7 @@ static int virtballoon_probe(struct virtio_device *vdev)
>   }
>  
>   vb->vb_dev_info.migratepage = virtballoon_migratepage;
> - vb->vb_dev_info.inode = alloc_anon_inode(balloon_mnt->mnt_sb);
> + vb->vb_dev_info.inode = alloc_anon_inode_sb(balloon_

Re: [PATCH 2/9] fs: add an argument-less alloc_anon_inode

[Christian Brauner]

On Tue, Mar 09, 2021 at 04:53:41PM +0100, Christoph Hellwig wrote:
> Add a new alloc_anon_inode helper that allocates an inode on
> the anon_inode file system.
> 
> Signed-off-by: Christoph Hellwig 
> ---

Looks good!
Reviewed-by: Christian Brauner 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 00/14] Add some DRM bridge drivers support for i.MX8qm/qxp SoCs

[Liu Ying]

Hi,

This is the v5 series to add some DRM bridge drivers support
for i.MX8qm/qxp SoCs.

The bridges may chain one by one to form display pipes to support
LVDS displays.  The relevant display controller is DPU embedded in
i.MX8qm/qxp SoCs.

The DPU KMS driver can be found at:
https://www.spinics.net/lists/arm-kernel/msg878542.html

This series supports the following display pipes:
1) i.MX8qxp:
prefetch eng -> DPU -> pixel combiner -> pixel link ->
pixel link to DPI(PXL2DPI) -> LVDS display bridge(LDB)

2) i.MX8qm:
prefetch eng -> DPU -> pixel combiner -> pixel link -> LVDS display bridge(LDB)


This series drops the patch 'phy: Add LVDS configuration options', as suggested
by Robert Foss, because it has already been sent with the following series to
add Mixel combo PHY found in i.MX8qxp:
https://www.spinics.net/lists/arm-kernel/msg879957.html

So, this version depends on that series.


Patch 1/14 and 2/14 add bus formats used by PXL2DPI.

Patch 7/14 adds dt-binding for Control and Status Registers module(a syscon
used by PXL2DPI and LDB), which references the PXL2DPI and LDB schemas.

Patch 10/14 adds a helper for LDB bridge drivers.

Patch 3/14 ~ 6/14, 8/14, 9/14 and 11/14 ~ 13/14 add drm bridge drivers and
dt-bindings support for the bridges.

Patch 14/14 updates MAINTAINERS.


I've tested this series with a koe,tx26d202vm0bwa dual link LVDS panel and
a LVDS to HDMI bridge(with a downstream drm bridge driver).


Welcome comments, thanks.

v4->v5:
* Drop the patch 'phy: Add LVDS configuration options'. (Robert)
* Add Robert's R-b tags on patch 1/14, 2/14, 4/14 and 6/14.
* Drop the 'PC_BUF_PARA_REG' register definition from the pixel combiner bridge
  driver(patch 4/14). (Robert)
* Make a comment occupy a line in the pixel link bridge driver(patch 6/14).
  (Robert)
* Introduce a new patch(patch 7/14) to add dt-binding for Control and Status
  Registers module. (Rob)
* Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
  driver and i.MX8qm LDB bridge driver, instead of a module.  Correspondingly,
  rename 'imx8{qm, qxp}-ldb.c' to 'imx8{qm, qxp}-ldb-drv.c'. (Robert)
* Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
  (Robert)
* s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/  for 'imx-ldb-helper.h'.

v3->v4:
* Use 'fsl,sc-resource' DT property to get the SCU resource ID associated with
  the PXL2DPI instance instead of using alias ID. (Rob)
* Add Rob's R-b tag on patch 11/14.

v2->v3:
* Drop 'fsl,syscon' DT properties from fsl,imx8qxp-ldb.yaml and
  fsl,imx8qxp-pxl2dpi.yaml. (Rob)
* Mention the CSR module controls LDB and PXL2DPI in fsl,imx8qxp-ldb.yaml and
  fsl,imx8qxp-pxl2dpi.yaml.
* Call syscon_node_to_regmap() to get regmaps from LDB bridge helper driver
  and PXL2DPI bridger driver instead of syscon_regmap_lookup_by_phandle().
* Drop two macros from pixel link bridge driver which help define functions
  and define them directly.
* Properly disable all pixel link controls to POR value by calling
  imx8qxp_pixel_link_disable_all_controls() from
  imx8qxp_pixel_link_bridge_probe().
* Add Rob's R-b tags on patch 4/14 and 6/14.

v1->v2:
* Rebase the series upon the latest drm-misc-next branch(5.11-rc2 based).
* Use graph schema in the dt-bindings of the bridges. (Laurent)
* Require all four pixel link output ports in fsl,imx8qxp-pixel-link.yaml.
  (Laurent)
* Side note i.MX8qm/qxp LDB official name 'pixel mapper' in 
fsl,imx8qxp-ldb.yaml.
  (Laurent)
* Mention pixel link is accessed via SCU firmware in 
fsl,imx8qxp-pixel-link.yaml.
  (Rob)
* Use enum instead of oneOf + const for the reg property of pixel combiner
  channels in fsl,imx8qxp-pixel-combiner.yaml. (Rob)
* Rewrite the function to find the next bridge in pixel link bridge driver
  by properly using OF APIs and dropping unnecessary DT validation. (Rob)
* Drop unnecessary port availability check in i.MX8qxp pixel link to DPI
  bridge driver.
* Drop unnecessary DT validation from i.MX8qxp LDB bridge driver.
* Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
  get the input remote endpoint in imx8qxp_ldb_set_di_id() of i.MX8qxp LDB
  bridge driver.
* Avoid using companion_port OF node after putting it in
  imx8qxp_ldb_parse_dt_companion() of i.MX8qxp LDB bridge driver.
* Drop unnecessary check for maximum available LDB channels from
  i.MX8qm LDB bridge driver.
* Mention i.MX8qm/qxp LDB official name 'pixel mapper' in i.MX8qm/qxp LDB
  bridge drivers and Kconfig help messages.

Liu Ying (14):
  media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
  media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner
  dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding
  drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support
  dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link
binding
  drm/bridge: imx: Add i.MX8qm/qxp display pixel link support
  dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module
binding
  dt-bin

[PATCH v5 01/14] media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner

[Liu Ying]

This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO
and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner.
The RGB pixels with padding low per component are transmitted on a 30-bit
input bus(10-bit per component) from a display controller or a 36-bit
output bus(12-bit per component) to a pixel link.

Reviewed-by: Robert Foss 
Signed-off-by: Liu Ying 
---
v4->v5:
* Add Robert's R-b tag.

v3->v4:
* No change.

v2->v3:
* No change.

v1->v2:
* No change.

 include/uapi/linux/media-bus-format.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 0dfc11e..ec3323d 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -34,7 +34,7 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x101e */
+/* RGB - next is   0x1022 */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
@@ -59,9 +59,13 @@
 #define MEDIA_BUS_FMT_RGB888_3X8_DELTA 0x101d
 #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG0x1011
 #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA   0x1012
+#define MEDIA_BUS_FMT_RGB666_1X30_CPADLO   0x101e
+#define MEDIA_BUS_FMT_RGB888_1X30_CPADLO   0x101f
 #define MEDIA_BUS_FMT_ARGB_1X320x100d
 #define MEDIA_BUS_FMT_RGB888_1X32_PADHI0x100f
 #define MEDIA_BUS_FMT_RGB101010_1X30   0x1018
+#define MEDIA_BUS_FMT_RGB666_1X36_CPADLO   0x1020
+#define MEDIA_BUS_FMT_RGB888_1X36_CPADLO   0x1021
 #define MEDIA_BUS_FMT_RGB121212_1X36   0x1019
 #define MEDIA_BUS_FMT_RGB161616_1X48   0x101a
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 04/14] drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support

[Liu Ying]

This patch adds a drm bridge driver for i.MX8qm/qxp pixel combiner.
The pixel combiner takes two output streams from a single display
controller and manipulates the two streams to support a number
of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured
as either one screen, two screens, or virtual screens.  The pixel
combiner is also responsible for generating some of the control signals
for the pixel link output channel.  For now, the driver only supports
the bypass mode.

Reviewed-by: Robert Foss 
Signed-off-by: Liu Ying 
---
v4->v5:
* Drop the 'PC_BUF_PARA_REG' register definition. (Robert)
* Add Robert's R-b tag.

v3->v4:
* No change.

v2->v3:
* No change.

v1->v2:
* No change.

 drivers/gpu/drm/bridge/Kconfig |   2 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/imx/Kconfig |   8 +
 drivers/gpu/drm/bridge/imx/Makefile|   1 +
 .../gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c| 448 +
 5 files changed, 460 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/imx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6c..84944e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -256,6 +256,8 @@ source "drivers/gpu/drm/bridge/adv7511/Kconfig"
 
 source "drivers/gpu/drm/bridge/cadence/Kconfig"
 
+source "drivers/gpu/drm/bridge/imx/Kconfig"
+
 source "drivers/gpu/drm/bridge/synopsys/Kconfig"
 
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc..bc80cae 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -27,4 +27,5 @@ obj-$(CONFIG_DRM_NWL_MIPI_DSI) += nwl-dsi.o
 
 obj-y += analogix/
 obj-y += cadence/
+obj-y += imx/
 obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
new file mode 100644
index ..f1c91b6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -0,0 +1,8 @@
+config DRM_IMX8QXP_PIXEL_COMBINER
+   tristate "Freescale i.MX8QM/QXP pixel combiner"
+   depends on OF
+   depends on COMMON_CLK
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable pixel combiner found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
new file mode 100644
index ..7d7c8d6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
new file mode 100644
index ..0b9403a
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-combiner.c
@@ -0,0 +1,448 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define PC_CTRL_REG0x0
+#define  PC_COMBINE_ENABLE BIT(0)
+#define  PC_DISP_BYPASS(n) BIT(1 + 21 * (n))
+#define  PC_DISP_HSYNC_POLARITY(n) BIT(2 + 11 * (n))
+#define  PC_DISP_HSYNC_POLARITY_POS(n) DISP_HSYNC_POLARITY(n)
+#define  PC_DISP_VSYNC_POLARITY(n) BIT(3 + 11 * (n))
+#define  PC_DISP_VSYNC_POLARITY_POS(n) DISP_VSYNC_POLARITY(n)
+#define  PC_DISP_DVALID_POLARITY(n)BIT(4 + 11 * (n))
+#define  PC_DISP_DVALID_POLARITY_POS(n)DISP_DVALID_POLARITY(n)
+#define  PC_VSYNC_MASK_ENABLE  BIT(5)
+#define  PC_SKIP_MODE  BIT(6)
+#define  PC_SKIP_NUMBER_MASK   GENMASK(12, 7)
+#define  PC_SKIP_NUMBER(n) FIELD_PREP(PC_SKIP_NUMBER_MASK, (n))
+#define  PC_DISP0_PIX_DATA_FORMAT_MASK GENMASK(18, 16)
+#define  PC_DISP0_PIX_DATA_FORMAT(fmt) \
+   FIELD_PREP(PC_DISP0_PIX_DATA_FORMAT_MASK, (fmt))
+#define  PC_DISP1_PIX_DATA_FORMAT_MASK GENMASK(21, 19)
+#define  PC_DISP1_PIX_DATA_FORMAT(fmt) \
+   FIELD_PREP(PC_DISP1_PIX_DATA_FORMAT_MASK, (fmt))
+
+#define PC_SW_RESET_REG0x20
+#define  PC_SW_RESET_N BIT(0)
+#define  PC_DISP_SW_RESET_N(n) BIT(1 + (n))
+#define  PC_FULL_RESET_N   (PC_SW_RESET_N |\
+PC_DISP_SW_RESET_N(0) |\
+PC_DISP_SW_RESET_N(1))
+
+#define PC_REG_SET 0x4
+#define PC_REG_CLR 0x8
+
+#define DRIVER_NAME"imx8qxp-pixel-combiner"
+
+enum imx8qxp_pc_pix_data_format {
+   RGB,
+   YUV444,
+   YUV422,
+   SPLIT_RGB,
+};
+
+struct imx8qxp_pc_channel {
+   struct drm_bridge bridge;
+  

[PATCH v5 02/14] media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner

[Liu Ying]

This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp
pixel combiner.  The RGB pixels with padding low per component are
transmitted on a 30-bit input bus(10-bit per component) from a display
controller or a 36-bit output bus(12-bit per component) to a pixel link.

Reviewed-by: Robert Foss 
Signed-off-by: Liu Ying 
---
v4->v5:
* Add Robert's R-b tag.

v3->v4:
* No change.

v2->v3:
* No change.

v1->v2:
* No change.

 .../userspace-api/media/v4l/subdev-formats.rst | 156 +
 1 file changed, 156 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst 
b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index 7f16cbe..201c16d 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -1488,6 +1488,80 @@ The following tables list existing packed RGB formats.
   - b\ :sub:`2`
   - b\ :sub:`1`
   - b\ :sub:`0`
+* .. _MEDIA-BUS-FMT-RGB666-1X30-CPADLO:
+
+  - MEDIA_BUS_FMT_RGB666_1X30-CPADLO
+  - 0x101e
+  -
+  - 0
+  - 0
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+* .. _MEDIA-BUS-FMT-RGB888-1X30-CPADLO:
+
+  - MEDIA_BUS_FMT_RGB888_1X30-CPADLO
+  - 0x101f
+  -
+  - 0
+  - 0
+  - r\ :sub:`7`
+  - r\ :sub:`6`
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - g\ :sub:`7`
+  - g\ :sub:`6`
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - b\ :sub:`7`
+  - b\ :sub:`6`
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - 0
+  - 0
 * .. _MEDIA-BUS-FMT-ARGB888-1X32:
 
   - MEDIA_BUS_FMT_ARGB888_1X32
@@ -1665,6 +1739,88 @@ The following table list existing packed 36bit wide RGB 
formats.
   - 2
   - 1
   - 0
+* .. _MEDIA-BUS-FMT-RGB666-1X36-CPADLO:
+
+  - MEDIA_BUS_FMT_RGB666_1X36_CPADLO
+  - 0x1020
+  -
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+  - 0
+* .. _MEDIA-BUS-FMT-RGB888-1X36-CPADLO:
+
+  - MEDIA_BUS_FMT_RGB888_1X36_CPADLO
+  - 0x1021
+  -
+  - r\ :sub:`7`
+  - r\ :sub:`6`
+  - r\ :sub:`5`
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - g\ :sub:`7`
+  - g\ :sub:`6`
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
+  - b\ :sub:`7`
+  - b\ :sub:`6`
+  - b\ :sub:`5`
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - 0
 * .. _MEDIA-BUS-FMT-RGB121212-1X36:
 
   - MEDIA_BUS_FMT_RGB121212_1X36
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 03/14] dt-bindings: display: bridge: Add i.MX8qm/qxp pixel combiner binding

[Liu Ying]

This patch adds bindings for i.MX8qm/qxp pixel combiner.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v4->v5:
* No change.

v3->v4:
* No change.

v2->v3:
* Add Rob's R-b tag.

v1->v2:
* Use graph schema. (Laurent)
* Use enum instead of oneOf + const for the reg property of pixel combiner
  channels. (Rob)

 .../display/bridge/fsl,imx8qxp-pixel-combiner.yaml | 144 +
 1 file changed, 144 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
new file mode 100644
index ..50bae21
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
@@ -0,0 +1,144 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-combiner.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Pixel Combiner
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp Pixel Combiner takes two output streams from a
+  single display controller and manipulates the two streams to support a number
+  of modes(bypass, pixel combine, YUV444 to YUV422, split_RGB) configured as
+  either one screen, two screens, or virtual screens.  The pixel combiner is
+  also responsible for generating some of the control signals for the pixel 
link
+  output channel.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qm-pixel-combiner
+  - fsl,imx8qxp-pixel-combiner
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: apb
+
+  power-domains:
+maxItems: 1
+
+patternProperties:
+  "^channel@[0-1]$":
+type: object
+description: Represents a display stream of pixel combiner.
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+description: The display stream index.
+enum: [ 0, 1 ]
+
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input endpoint of the display stream.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output endpoint of the display stream.
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - reg
+  - port@0
+  - port@1
+
+additionalProperties: false
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - reg
+  - clocks
+  - clock-names
+  - power-domains
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+pixel-combiner@5602 {
+compatible = "fsl,imx8qxp-pixel-combiner";
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0x5602 0x1>;
+clocks = <&dc0_pixel_combiner_lpcg IMX_LPCG_CLK_4>;
+clock-names = "apb";
+power-domains = <&pd IMX_SC_R_DC_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch0_dc0_dpu_disp0: endpoint {
+remote-endpoint = <&dc0_dpu_disp0_dc0_pixel_combiner_ch0>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch0_dc0_pixel_link0: endpoint {
+remote-endpoint = 
<&dc0_pixel_link0_dc0_pixel_combiner_ch0>;
+};
+};
+};
+
+channel@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+port@0 {
+reg = <0>;
+
+dc0_pixel_combiner_ch1_dc0_dpu_disp1: endpoint {
+remote-endpoint = <&dc0_dpu_disp1_dc0_pixel_combiner_ch1>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+dc0_pixel_combiner_ch1_dc0_pixel_link1: endpoint {
+remote-endpoint = 
<&dc0_pixel_link1_dc0_pixel_combiner_ch1>;
+};
+};
+};
+};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 05/14] dt-bindings: display: bridge: Add i.MX8qm/qxp display pixel link binding

[Liu Ying]

This patch adds bindings for i.MX8qm/qxp display pixel link.

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v4->v5:
* No change.

v3->v4:
* No change.

v2->v3:
* Add Rob's R-b tag.

v1->v2:
* Use graph schema. (Laurent)
* Require all four pixel link output ports. (Laurent)
* Mention pixel link is accessed via SCU firmware. (Rob)

 .../display/bridge/fsl,imx8qxp-pixel-link.yaml | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
new file mode 100644
index ..3af67cc
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pixel-link.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Display Pixel Link
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard
+  asynchronous linkage between pixel sources(display controller or
+  camera module) and pixel consumers(imaging or displays).
+  It consists of two distinct functions, a pixel transfer function and a
+  control interface.  Multiple pixel channels can exist per one control 
channel.
+  This binding documentation is only for pixel links whose pixel sources are
+  display controllers.
+
+  The i.MX8qm/qxp Display Pixel Link is accessed via System Controller 
Unit(SCU)
+  firmware.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qm-dc-pixel-link
+  - fsl,imx8qxp-dc-pixel-link
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: The pixel link input port node from upstream video source.
+
+patternProperties:
+  "^port@[1-4]$":
+$ref: /schemas/graph.yaml#/properties/port
+description: The pixel link output port node to downstream bridge.
+
+required:
+  - port@0
+  - port@1
+  - port@2
+  - port@3
+  - port@4
+
+required:
+  - compatible
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+dc0-pixel-link0 {
+compatible = "fsl,imx8qxp-dc-pixel-link";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+/* from dc0 pixel combiner channel0 */
+port@0 {
+reg = <0>;
+
+dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint {
+remote-endpoint = 
<&dc0_pixel_combiner_ch0_dc0_pixel_link0>;
+};
+};
+
+/* to PXL2DPIs in MIPI/LVDS combo subsystems */
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&mipi_lvds_0_pxl2dpi_dc0_pixel_link0>;
+};
+
+dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 {
+reg = <1>;
+remote-endpoint = <&mipi_lvds_1_pxl2dpi_dc0_pixel_link0>;
+};
+};
+
+/* unused */
+port@2 {
+reg = <2>;
+};
+
+/* unused */
+port@3 {
+reg = <3>;
+};
+
+/* to imaging subsystem */
+port@4 {
+reg = <4>;
+};
+};
+};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 06/14] drm/bridge: imx: Add i.MX8qm/qxp display pixel link support

[Liu Ying]

This patch adds a drm bridge driver for i.MX8qm/qxp display pixel link.
The pixel link forms a standard asynchronous linkage between
pixel sources(display controller or camera module) and pixel
consumers(imaging or displays).  It consists of two distinct
functions, a pixel transfer function and a control interface.

Reviewed-by: Robert Foss 
Signed-off-by: Liu Ying 
---
v4->v5:
* Make a comment occupy a line. (Robert)
* Add Robert's R-b tag.

v3->v4:
* No change.

v2->v3:
* Drop two macros which help define functions and define them directly.
* Properly disable all pixel link controls to POR value by calling
  imx8qxp_pixel_link_disable_all_controls() from
  imx8qxp_pixel_link_bridge_probe().

v1->v2:
* Rewrite the function to find the next bridge by properly using OF APIs
  and dropping unnecessary DT validation. (Rob)

 drivers/gpu/drm/bridge/imx/Kconfig  |   8 +
 drivers/gpu/drm/bridge/imx/Makefile |   1 +
 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c | 427 
 3 files changed, 436 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index f1c91b6..4d1f027 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -6,3 +6,11 @@ config DRM_IMX8QXP_PIXEL_COMBINER
help
  Choose this to enable pixel combiner found in
  Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK
+   tristate "Freescale i.MX8QM/QXP display pixel link"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable display pixel link found in
+ Freescale i.MX8qm/qxp processors.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index 7d7c8d6..c15469f 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
new file mode 100644
index ..a549624
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pixel-link.c
@@ -0,0 +1,427 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRIVER_NAME"imx8qxp-display-pixel-link"
+#define PL_MAX_MST_ADDR3
+#define PL_MAX_NEXT_BRIDGES2
+
+struct imx8qxp_pixel_link {
+   struct drm_bridge bridge;
+   struct drm_bridge *next_bridge;
+   struct device *dev;
+   struct imx_sc_ipc *ipc_handle;
+   int id;
+   int stream_id;
+   int dc_id;
+   u32 sink_rsc;
+   u32 mst_addr;
+   u8 mst_addr_ctrl;
+   u8 mst_en_ctrl;
+   u8 mst_vld_ctrl;
+   u8 sync_ctrl;
+};
+
+static void imx8qxp_pixel_link_enable_mst_en(struct imx8qxp_pixel_link *pl)
+{
+   int ret;
+
+   ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_en_ctrl, true);
+   if (ret)
+   DRM_DEV_ERROR(pl->dev,
+   "failed to enable DC%d stream%d pixel link mst_en: 
%d\n",
+   pl->dc_id, pl->stream_id, ret);
+}
+
+static void imx8qxp_pixel_link_enable_mst_vld(struct imx8qxp_pixel_link *pl)
+{
+   int ret;
+
+   ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_vld_ctrl, true);
+   if (ret)
+   DRM_DEV_ERROR(pl->dev,
+   "failed to enable DC%d stream%d pixel link mst_vld: %d\n",
+   pl->dc_id, pl->stream_id, ret);
+}
+
+static void imx8qxp_pixel_link_enable_sync(struct imx8qxp_pixel_link *pl)
+{
+   int ret;
+
+   ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->sync_ctrl, true);
+   if (ret)
+   DRM_DEV_ERROR(pl->dev,
+   "failed to enable DC%d stream%d pixel link sync: %d\n",
+   pl->dc_id, pl->stream_id, ret);
+}
+
+static int imx8qxp_pixel_link_disable_mst_en(struct imx8qxp_pixel_link *pl)
+{
+   int ret;
+
+   ret = imx_sc_misc_set_control(pl->ipc_handle, pl->sink_rsc,
+ pl->mst_en_ctrl, false);
+   if (ret)
+   DRM_DEV_ERROR(pl->dev,
+   "failed to disable DC%d stream%d pixel link mst_en: %d\n",
+   pl->dc_id, pl->stream_id, ret);
+
+   return ret;
+}
+
+static int imx8qxp_pixel_link_disable_mst_vld(struct imx8qxp_pixel_link *pl)
+{
+   int ret;
+
+   ret = imx_sc_misc_set_control(pl->ipc

[PATCH v5 08/14] dt-bindings: display: bridge: Add i.MX8qxp pixel link to DPI binding

[Liu Ying]

This patch adds bindings for i.MX8qxp pixel link to DPI(PXL2DPI).

Signed-off-by: Liu Ying 
---
v4->v5:
* No change.

v3->v4:
* Add 'fsl,sc-resource' property. (Rob)

v2->v3:
* Drop 'fsl,syscon' property. (Rob)
* Mention the CSR module controls PXL2DPI.

v1->v2:
* Use graph schema. (Laurent)

 .../display/bridge/fsl,imx8qxp-pxl2dpi.yaml| 108 +
 1 file changed, 108 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
new file mode 100644
index ..e4e77fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-pxl2dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qxp Pixel Link to Display Pixel Interface
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qxp Pixel Link to Display Pixel Interface(PXL2DPI)
+  interfaces the pixel link 36-bit data output and the DSI controller’s
+  MIPI-DPI 24-bit data input, and inputs of LVDS Display Bridge(LDB) module
+  used in LVDS mode, to remap the pixel color codings between those modules.
+  This module is purely combinatorial.
+
+  The i.MX8qxp PXL2DPI is controlled by Control and Status Registers(CSR) 
module.
+  The CSR module, as a system controller, contains the PXL2DPI's configuration
+  register.
+
+properties:
+  compatible:
+const: fsl,imx8qxp-pxl2dpi
+
+  fsl,sc-resource:
+$ref: /schemas/types.yaml#/definitions/uint32
+description: The SCU resource ID associated with this PXL2DPI instance.
+
+  power-domains:
+maxItems: 1
+
+  fsl,companion-pxl2dpi:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  A phandle which points to companion PXL2DPI which is used by downstream
+  LVDS Display Bridge(LDB) in split mode.
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: The PXL2DPI input port node from pixel link.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: The PXL2DPI output port node to downstream bridge.
+
+required:
+  - port@0
+  - port@1
+
+required:
+  - compatible
+  - fsl,sc-resource
+  - power-domains
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pxl2dpi {
+compatible = "fsl,imx8qxp-pxl2dpi";
+fsl,sc-resource = ;
+power-domains = <&pd IMX_SC_R_MIPI_0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link0: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&dc_pixel_link0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_dc_pixel_link1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&dc_pixel_link1_mipi_lvds_0_pxl2dpi>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+reg = <0>;
+remote-endpoint = 
<&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+reg = <1>;
+remote-endpoint = 
<&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+};
+};
+};
+};
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5 07/14] dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding

[Liu Ying]

This patch adds bindings for i.MX8qm/qxp Control and Status Registers module.

Signed-off-by: Liu Ying 
---
v4->v5:
* Newly introduced in v5. (Rob)

 .../devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml   | 202 +
 1 file changed, 202 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml

diff --git a/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml 
b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
new file mode 100644
index ..0e724d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl,imx8qxp-csr.yaml
@@ -0,0 +1,202 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/fsl,imx8qxp-csr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp Control and Status Registers Module Bindings
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  As a system controller, the Freescale i.MX8qm/qxp Control and Status
+  Registers(CSR) module represents a set of miscellaneous registers of a
+  specific subsystem.  It may provide control and/or status report interfaces
+  to a mix of standalone hardware devices within that subsystem.  One typical
+  use-case is for some other nodes to acquire a reference to the syscon node
+  by phandle, and the other typical use-case is that the operating system
+  should consider all subnodes of the CSR module as separate child devices.
+
+select:
+  properties:
+compatible:
+  contains:
+enum:
+  - fsl,imx8qxp-mipi-lvds-csr
+  - fsl,imx8qm-lvds-csr
+  required:
+- compatible
+
+properties:
+  $nodename:
+pattern: "^syscon@[0-9a-f]+$"
+
+  compatible:
+items:
+  - enum:
+  - fsl,imx8qxp-mipi-lvds-csr
+  - fsl,imx8qm-lvds-csr
+  - const: syscon
+  - const: simple-mfd
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+const: ipg
+
+patternProperties:
+  "^(ldb|phy|pxl2dpi)$":
+type: object
+description: The possible child devices of the CSR module.
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: fsl,imx8qxp-mipi-lvds-csr
+then:
+  required:
+- pxl2dpi
+- ldb
+
+  - if:
+  properties:
+compatible:
+  contains:
+const: fsl,imx8qm-lvds-csr
+then:
+  required:
+- phy
+- ldb
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+mipi_lvds_0_csr: syscon@56221000 {
+compatible = "fsl,imx8qxp-mipi-lvds-csr", "syscon", "simple-mfd";
+reg = <0x56221000 0x1000>;
+clocks = <&mipi_lvds_0_di_mipi_lvds_regs_lpcg IMX_LPCG_CLK_4>;
+clock-names = "ipg";
+
+mipi_lvds_0_pxl2dpi: pxl2dpi {
+compatible = "fsl,imx8qxp-pxl2dpi";
+fsl,sc-resource = ;
+power-domains = <&pd IMX_SC_R_MIPI_0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+
+mipi_lvds_0_pxl2dpi_dc0_pixel_link0: endpoint@0 {
+reg = <0>;
+remote-endpoint = 
<&dc0_pixel_link0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_dc0_pixel_link1: endpoint@1 {
+reg = <1>;
+remote-endpoint = 
<&dc0_pixel_link1_mipi_lvds_0_pxl2dpi>;
+};
+};
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <1>;
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch0: endpoint@0 {
+reg = <0>;
+remote-endpoint = 
<&mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi>;
+};
+
+mipi_lvds_0_pxl2dpi_mipi_lvds_0_ldb_ch1: endpoint@1 {
+reg = <1>;
+remote-endpoint = 
<&mipi_lvds_0_ldb_ch1_mipi_lvds_0_pxl2dpi>;
+};
+};
+};
+};
+
+mipi_lvds_0_ldb: ldb {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx8qxp-ldb";
+clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
+ <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
+clock-names = "pixel", "bypass";
+power-domains = <&pd IMX_SC_R_LVDS_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+phys = <&mipi_lvds_0_phy>;
+phy-names = "lvds_phy";
+
+port@0 {
+ 

[PATCH v5 09/14] drm/bridge: imx: Add i.MX8qxp pixel link to DPI support

[Liu Ying]

This patch adds a drm bridge driver for i.MX8qxp pixel link to display
pixel interface(PXL2DPI).  The PXL2DPI interfaces the pixel link 36-bit
data output and the DSI controller’s MIPI-DPI 24-bit data input, and
inputs of LVDS Display Bridge(LDB) module used in LVDS mode, to remap
the pixel color codings between those modules. The PXL2DPI is purely
combinatorial.

Signed-off-by: Liu Ying 
---
v4->v5:
* No change.

v3->v4:
* Use 'fsl,sc-resource' DT property to get the SCU resource ID associated with
  the PXL2DPI instance instead of using alias ID. (Rob)

v2->v3:
* Call syscon_node_to_regmap() to get regmap instead of
  syscon_regmap_lookup_by_phandle().

v1->v2:
* Drop unnecessary port availability check.

 drivers/gpu/drm/bridge/imx/Kconfig   |   8 +
 drivers/gpu/drm/bridge/imx/Makefile  |   1 +
 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 485 +++
 3 files changed, 494 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 4d1f027..1ea1ce7 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -14,3 +14,11 @@ config DRM_IMX8QXP_PIXEL_LINK
help
  Choose this to enable display pixel link found in
  Freescale i.MX8qm/qxp processors.
+
+config DRM_IMX8QXP_PIXEL_LINK_TO_DPI
+   tristate "Freescale i.MX8QXP pixel link to display pixel interface"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable pixel link to display pixel interface(PXL2DPI)
+ found in Freescale i.MX8qxp processor.
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index c15469f..e74dd64 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
+obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
new file mode 100644
index ..6696855
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -0,0 +1,485 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define PXL2DPI_CTRL   0x40
+#define  CFG1_16BIT0x0
+#define  CFG2_16BIT0x1
+#define  CFG3_16BIT0x2
+#define  CFG1_18BIT0x3
+#define  CFG2_18BIT0x4
+#define  CFG_24BIT 0x5
+
+#define DRIVER_NAME"imx8qxp-pxl2dpi"
+
+struct imx8qxp_pxl2dpi {
+   struct regmap *regmap;
+   struct drm_bridge bridge;
+   struct drm_bridge *next_bridge;
+   struct drm_bridge *companion;
+   struct device *dev;
+   struct imx_sc_ipc *ipc_handle;
+   u32 sc_resource;
+   u32 in_bus_format;
+   u32 out_bus_format;
+   u32 pl_sel;
+};
+
+#define bridge_to_p2d(b)   container_of(b, struct imx8qxp_pxl2dpi, bridge)
+
+static int imx8qxp_pxl2dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+   DRM_DEV_ERROR(p2d->dev,
+ "do not support creating a drm_connector\n");
+   return -EINVAL;
+   }
+
+   if (!bridge->encoder) {
+   DRM_DEV_ERROR(p2d->dev, "missing encoder\n");
+   return -ENODEV;
+   }
+
+   return drm_bridge_attach(bridge->encoder,
+p2d->next_bridge, bridge,
+DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+}
+
+static int
+imx8qxp_pxl2dpi_bridge_atomic_check(struct drm_bridge *bridge,
+   struct drm_bridge_state *bridge_state,
+   struct drm_crtc_state *crtc_state,
+   struct drm_connector_state *conn_state)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+
+   p2d->in_bus_format = bridge_state->input_bus_cfg.format;
+   p2d->out_bus_format = bridge_state->output_bus_cfg.format;
+
+   return 0;
+}
+
+static void
+imx8qxp_pxl2dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct imx8qxp_pxl2dpi *p2d = bridge->driver_private;
+   struct imx8qxp_pxl2dpi *companion_p2d;
+   int ret;
+
+   ret = pm_runtime_get_sync(p2d->dev);
+   if (ret < 0)
+   DRM_DEV_ERROR(p2d->dev,
+ "failed to 

[PATCH v5 10/14] drm/bridge: imx: Add LDB driver helper support

[Liu Ying]

This patch adds a helper to support LDB drm bridge drivers for
i.MX SoCs.  Helper functions supported by this helper should
implement common logics for all LDB modules embedded in i.MX SoCs.

Signed-off-by: Liu Ying 
---
v4->v5:
* Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
  driver and i.MX8qm LDB bridge driver. (Robert)
* Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
  (Robert)
* s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/  for 'imx-ldb-helper.h'.

v3->v4:
* No change.

v2->v3:
* Call syscon_node_to_regmap() to get regmap instead of
  syscon_regmap_lookup_by_phandle().

v1->v2:
* No change.

 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 232 
 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h |  98 
 2 files changed, 330 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
 create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h

diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c 
b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
new file mode 100644
index ..d01c4ff9
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ * Copyright 2019,2020 NXP
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "imx-ldb-helper.h"
+
+bool ldb_channel_is_single_link(struct ldb_channel *ldb_ch)
+{
+   return ldb_ch->link_type == LDB_CH_SINGLE_LINK;
+}
+
+bool ldb_channel_is_split_link(struct ldb_channel *ldb_ch)
+{
+   return ldb_ch->link_type == LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS ||
+  ldb_ch->link_type == LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
+}
+
+int ldb_bridge_atomic_check_helper(struct drm_bridge *bridge,
+  struct drm_bridge_state *bridge_state,
+  struct drm_crtc_state *crtc_state,
+  struct drm_connector_state *conn_state)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+
+   ldb_ch->in_bus_format = bridge_state->input_bus_cfg.format;
+   ldb_ch->out_bus_format = bridge_state->output_bus_cfg.format;
+
+   return 0;
+}
+
+void ldb_bridge_mode_set_helper(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+   bool is_split = ldb_channel_is_split_link(ldb_ch);
+
+   if (is_split)
+   ldb->ldb_ctrl |= LDB_SPLIT_MODE_EN;
+
+   switch (ldb_ch->out_bus_format) {
+   case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
+   if (ldb_ch->chno == 0 || is_split)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24;
+   if (ldb_ch->chno == 1 || is_split)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24;
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
+   if (ldb_ch->chno == 0 || is_split)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24 |
+LDB_BIT_MAP_CH0_JEIDA;
+   if (ldb_ch->chno == 1 || is_split)
+   ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24 |
+LDB_BIT_MAP_CH1_JEIDA;
+   break;
+   }
+}
+
+void ldb_bridge_enable_helper(struct drm_bridge *bridge)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+
+   /*
+* Platform specific bridge drivers should set ldb_ctrl properly
+* for the enablement, so just write the ctrl_reg here.
+*/
+   regmap_write(ldb->regmap, ldb->ctrl_reg, ldb->ldb_ctrl);
+}
+
+void ldb_bridge_disable_helper(struct drm_bridge *bridge)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+   bool is_split = ldb_channel_is_split_link(ldb_ch);
+
+   if (ldb_ch->chno == 0 || is_split)
+   ldb->ldb_ctrl &= ~LDB_CH0_MODE_EN_MASK;
+   if (ldb_ch->chno == 1 || is_split)
+   ldb->ldb_ctrl &= ~LDB_CH1_MODE_EN_MASK;
+
+   regmap_write(ldb->regmap, ldb->ctrl_reg, ldb->ldb_ctrl);
+}
+
+int ldb_bridge_attach_helper(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
+{
+   struct ldb_channel *ldb_ch = bridge->driver_private;
+   struct ldb *ldb = ldb_ch->ldb;
+
+   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
+   DRM_DEV_ERROR(ldb->dev,
+ "do not support creating a drm_connector\n");
+   return -EINVAL;
+   }
+
+   if (!bridge->encoder) {
+   DRM_DEV_ERROR(ldb->dev, "missing encoder\n");
+

[PATCH v5 11/14] dt-bindings: display: bridge: Add i.MX8qm/qxp LVDS display bridge binding

[Liu Ying]

This patch adds bindings for i.MX8qm/qxp LVDS display bridge(LDB).

Reviewed-by: Rob Herring 
Signed-off-by: Liu Ying 
---
v4->v5:
* No change.

v3->v4:
* Add Rob's R-b tag.

v2->v3:
* Drop 'fsl,syscon' property. (Rob)
* Mention the CSR module controls LDB.

v1->v2:
* Use graph schema. (Laurent)
* Side note i.MX8qxp LDB official name 'pixel mapper'. (Laurent)

 .../bindings/display/bridge/fsl,imx8qxp-ldb.yaml   | 173 +
 1 file changed, 173 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml

diff --git 
a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml 
b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
new file mode 100644
index ..9454300
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
@@ -0,0 +1,173 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/fsl,imx8qxp-ldb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX8qm/qxp LVDS Display Bridge
+
+maintainers:
+  - Liu Ying 
+
+description: |
+  The Freescale i.MX8qm/qxp LVDS Display Bridge(LDB) has two channels.
+
+  The i.MX8qm/qxp LDB is controlled by Control and Status Registers(CSR) 
module.
+  The CSR module, as a system controller, contains the LDB's configuration
+  registers.
+
+  For i.MX8qxp LDB, each channel supports up to 24bpp parallel input color
+  format and can map the input to VESA or JEIDA standards.  The two channels
+  cannot be used simultaneously, that is to say, the user should pick one of
+  them to use.  Two LDB channels from two LDB instances can work together in
+  LDB split mode to support a dual link LVDS display.  The channel indexes
+  have to be different.  Channel0 outputs odd pixels and channel1 outputs
+  even pixels.
+
+  For i.MX8qm LDB, each channel additionally supports up to 30bpp parallel
+  input color format.  The two channels can be used simultaneously, either
+  in dual mode or split mode.  In dual mode, the two channels output identical
+  data.  In split mode, channel0 outputs odd pixels and channel1 outputs even
+  pixels.
+
+  A side note is that i.MX8qm/qxp LDB is officially called pixel mapper in
+  the SoC reference manuals.  The pixel mapper uses logic of LDBs embedded in
+  i.MX6qdl/sx SoCs, i.e., it is essentially based on them.  To keep the naming
+  consistency, this binding calls it LDB.
+
+properties:
+  compatible:
+enum:
+  - fsl,imx8qm-ldb
+  - fsl,imx8qxp-ldb
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  clocks:
+items:
+  - description: pixel clock
+  - description: bypass clock
+
+  clock-names:
+items:
+  - const: pixel
+  - const: bypass
+
+  power-domains:
+maxItems: 1
+
+  fsl,companion-ldb:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: |
+  A phandle which points to companion LDB which is used in LDB split mode.
+
+patternProperties:
+  "^channel@[0-1]$":
+type: object
+description: Represents a channel of LDB.
+
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reg:
+description: The channel index.
+enum: [ 0, 1 ]
+
+  phys:
+description: A phandle to the phy module representing the LVDS PHY.
+maxItems: 1
+
+  phy-names:
+const: lvds_phy
+
+  port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description: Input port of the channel.
+
+  port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: Output port of the channel.
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - reg
+  - phys
+  - phy-names
+
+additionalProperties: false
+
+required:
+  - compatible
+  - "#address-cells"
+  - "#size-cells"
+  - clocks
+  - clock-names
+  - power-domains
+  - channel@0
+  - channel@1
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: fsl,imx8qm-ldb
+then:
+  properties:
+fsl,companion-ldb: false
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+ldb {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "fsl,imx8qxp-ldb";
+clocks = <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_MISC2>,
+ <&clk IMX_SC_R_LVDS_0 IMX_SC_PM_CLK_BYPASS>;
+clock-names = "pixel", "bypass";
+power-domains = <&pd IMX_SC_R_LVDS_0>;
+
+channel@0 {
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0>;
+phys = <&mipi_lvds_0_phy>;
+phy-names = "lvds_phy";
+
+port@0 {
+reg = <0>;
+
+mipi_lvds_0_ldb_ch0_mipi_lvds_0_pxl2dpi: endpoint {
+remote-endpoint = 
<&mipi_lvds_0_pxl2dpi_mipi_lvds_0_

[PATCH v5 12/14] drm/bridge: imx: Add LDB support for i.MX8qxp

[Liu Ying]

This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
which is officially named as pixel mapper.  The LDB has two channels.
Each of them supports up to 24bpp parallel input color format and can map
the input to VESA or JEIDA standards.  The two channels cannot be used
simultaneously, that is to say, the user should pick one of them to use.
Two LDB channels from two LDB instances can work together in LDB split
mode to support a dual link LVDS display.  The channel indexes have to be
different.  Channel0 outputs odd pixels and channel1 outputs even pixels.
This patch supports the LDB single mode and split mode.

Signed-off-by: Liu Ying 
---
Note that this patch depends on the patch 'phy: Add LVDS configuration options',
which has already been sent with the following series to add Mixel combo PHY
found in i.MX8qxp:
https://www.spinics.net/lists/arm-kernel/msg879957.html

v4->v5:
* Link with the imx-ldb-helper object. (Robert)
* Correspondingly, rename 'imx8qxp-ldb.c' to 'imx8qxp-ldb-drv.c'.

v3->v4:
* No change.

v2->v3:
* No change.

v1->v2:
* Drop unnecessary DT validation.
* Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
  get the input remote endpoint in imx8qxp_ldb_set_di_id().
* Avoid using companion_port OF node after putting it in
  imx8qxp_ldb_parse_dt_companion().
* Mention i.MX8qxp LDB official name 'pixel mapper' in the bridge driver
  and Kconfig help message.

 drivers/gpu/drm/bridge/imx/Kconfig   |   9 +
 drivers/gpu/drm/bridge/imx/Makefile  |   3 +
 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 720 +++
 3 files changed, 732 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 1ea1ce7..94f8db4d 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -1,3 +1,12 @@
+config DRM_IMX8QXP_LDB
+   tristate "Freescale i.MX8QXP LVDS display bridge"
+   depends on OF
+   depends on COMMON_CLK
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable the internal LVDS Display Bridge(LDB) found in
+ Freescale i.MX8qxp processor.  Official name of LDB is pixel mapper.
+
 config DRM_IMX8QXP_PIXEL_COMBINER
tristate "Freescale i.MX8QM/QXP pixel combiner"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index e74dd64..96d5d1e 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,3 +1,6 @@
+imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
+obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
+
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
 obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c 
b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
new file mode 100644
index ..d7f59c1
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
@@ -0,0 +1,720 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-ldb-helper.h"
+
+#define  LDB_CH_SEL(1 << 28)
+
+#define SS_CTRL0x20
+#define  CH_HSYNC_M(id)BIT(0 + ((id) * 2))
+#define  CH_VSYNC_M(id)BIT(1 + ((id) * 2))
+#define  CH_PHSYNC(id) BIT(0 + ((id) * 2))
+#define  CH_PVSYNC(id) BIT(1 + ((id) * 2))
+
+#define DRIVER_NAME"imx8qxp-ldb"
+
+struct imx8qxp_ldb_channel {
+   struct ldb_channel base;
+   struct phy *phy;
+   unsigned int di_id;
+};
+
+struct imx8qxp_ldb {
+   struct ldb base;
+   struct device *dev;
+   struct imx8qxp_ldb_channel channel[MAX_LDB_CHAN_NUM];
+   struct clk *clk_pixel;
+   struct clk *clk_bypass;
+   struct drm_bridge *companion;
+   int active_chno;
+};
+
+static inline struct imx8qxp_ldb_channel *
+base_to_imx8qxp_ldb_channel(struct ldb_channel *base)
+{
+   return container_of(base, struct imx8qxp_ldb_channel, base);
+}
+
+static inline struct imx8qxp_ldb *base_to_imx8qxp_ldb(struct ldb *base)
+{
+   return container_of(base, struct imx8qxp_ldb, base);
+}
+
+static void imx8qxp_ldb_set_phy_cfg(struct imx8qxp_ldb *imx8qxp_ldb,
+   unsigned long di_clk, bool is_split,
+   struct phy_configure_opts_lvds *phy_cfg)
+{
+   phy_cfg->bits_per_lane_and_dclk_cycle = 7;
+   phy_cfg->lanes = 4;
+
+   if (is_split) {
+   phy_cfg->differential_clk_rate = di_clk / 2;
+   phy_cfg->is_slave = !imx8qxp_ldb->companion;
+   } else {
+   phy_cfg->differen

[PATCH v5 13/14] drm/bridge: imx: Add LDB support for i.MX8qm

[Liu Ying]

This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB)
which is officially named as pixel mapper.  The LDB has two channels.
Each of them supports up to 30bpp parallel input color format and can
map the input to VESA or JEIDA standards.  The two channels can be used
simultaneously, either in dual mode or split mode.  In dual mode, the
two channels output identical data.  In split mode, channel0 outputs
odd pixels and channel1 outputs even pixels.  This patch supports the
LDB single mode and split mode.

Signed-off-by: Liu Ying 
---
Note that this patch depends on the patch 'phy: Add LVDS configuration options',
which has already been sent with the following series to add Mixel combo PHY
found in i.MX8qxp:
https://www.spinics.net/lists/arm-kernel/msg879957.html

v4->v5:
* Link with the imx-ldb-helper object. (Robert)
* Correspondingly, rename 'imx8qm-ldb.c' to 'imx8qm-ldb-drv.c'.

v3->v4:
* No change.

v2->v3:
* No change.

v1->v2:
* Drop unnecessary check for maximum available LDB channels.
* Mention i.MX8qm LDB official name 'pixel mapper' in the bridge driver
  and Kconfig help message.

 drivers/gpu/drm/bridge/imx/Kconfig  |   9 +
 drivers/gpu/drm/bridge/imx/Makefile |   3 +
 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 586 
 3 files changed, 598 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c

diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
b/drivers/gpu/drm/bridge/imx/Kconfig
index 94f8db4d..3a8683f 100644
--- a/drivers/gpu/drm/bridge/imx/Kconfig
+++ b/drivers/gpu/drm/bridge/imx/Kconfig
@@ -1,3 +1,12 @@
+config DRM_IMX8QM_LDB
+   tristate "Freescale i.MX8QM LVDS display bridge"
+   depends on OF
+   depends on COMMON_CLK
+   select DRM_KMS_HELPER
+   help
+ Choose this to enable the internal LVDS Display Bridge(LDB) found in
+ Freescale i.MX8qm processor.  Official name of LDB is pixel mapper.
+
 config DRM_IMX8QXP_LDB
tristate "Freescale i.MX8QXP LVDS display bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
b/drivers/gpu/drm/bridge/imx/Makefile
index 96d5d1e..aa90ec8 100644
--- a/drivers/gpu/drm/bridge/imx/Makefile
+++ b/drivers/gpu/drm/bridge/imx/Makefile
@@ -1,3 +1,6 @@
+imx8qm-ldb-objs := imx-ldb-helper.o imx8qm-ldb-drv.o
+obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
+
 imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
 obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
 
diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c 
b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
new file mode 100644
index ..6c92636
--- /dev/null
+++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
@@ -0,0 +1,586 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-ldb-helper.h"
+
+#define  LDB_CH0_10BIT_EN  (1 << 22)
+#define  LDB_CH1_10BIT_EN  (1 << 23)
+#define  LDB_CH0_DATA_WIDTH_24BIT  (1 << 24)
+#define  LDB_CH1_DATA_WIDTH_24BIT  (1 << 26)
+#define  LDB_CH0_DATA_WIDTH_30BIT  (2 << 24)
+#define  LDB_CH1_DATA_WIDTH_30BIT  (2 << 26)
+
+#define SS_CTRL0x20
+#define  CH_HSYNC_M(id)BIT(0 + ((id) * 2))
+#define  CH_VSYNC_M(id)BIT(1 + ((id) * 2))
+#define  CH_PHSYNC(id) BIT(0 + ((id) * 2))
+#define  CH_PVSYNC(id) BIT(1 + ((id) * 2))
+
+#define DRIVER_NAME"imx8qm-ldb"
+
+struct imx8qm_ldb_channel {
+   struct ldb_channel base;
+   struct phy *phy;
+};
+
+struct imx8qm_ldb {
+   struct ldb base;
+   struct device *dev;
+   struct imx8qm_ldb_channel channel[MAX_LDB_CHAN_NUM];
+   struct clk *clk_pixel;
+   struct clk *clk_bypass;
+   int active_chno;
+};
+
+static inline struct imx8qm_ldb_channel *
+base_to_imx8qm_ldb_channel(struct ldb_channel *base)
+{
+   return container_of(base, struct imx8qm_ldb_channel, base);
+}
+
+static inline struct imx8qm_ldb *base_to_imx8qm_ldb(struct ldb *base)
+{
+   return container_of(base, struct imx8qm_ldb, base);
+}
+
+static void imx8qm_ldb_set_phy_cfg(struct imx8qm_ldb *imx8qm_ldb,
+  unsigned long di_clk,
+  bool is_split, bool is_slave,
+  struct phy_configure_opts_lvds *phy_cfg)
+{
+   phy_cfg->bits_per_lane_and_dclk_cycle = 7;
+   phy_cfg->lanes = 4;
+   phy_cfg->differential_clk_rate = is_split ? di_clk / 2 : di_clk;
+   phy_cfg->is_slave = is_slave;
+}
+
+static int imx8qm_ldb_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+

[PATCH v5 14/14] MAINTAINERS: add maintainer for DRM bridge drivers for i.MX SoCs

[Liu Ying]

Add myself as the maintainer of DRM bridge drivers for i.MX SoCs.

Signed-off-by: Liu Ying 
---
v4->v5:
* No change.

v3->v4:
* No change.

v2->v3:
* No change.

v1->v2:
* No change.

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

diff --git a/MAINTAINERS b/MAINTAINERS
index 63bd69c..6e0c019 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5892,6 +5892,16 @@ F:   Documentation/devicetree/bindings/display/imx/
 F: drivers/gpu/drm/imx/
 F: drivers/gpu/ipu-v3/
 
+DRM DRIVERS FOR FREESCALE IMX BRIDGE
+M: Liu Ying 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-ldb.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-combiner.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml
+F: 
Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pxl2dpi.yaml
+F: drivers/gpu/drm/bridge/imx/
+
 DRM DRIVERS FOR GMA500 (Poulsbo, Moorestown and derivative chipsets)
 M: Patrik Jakobsson 
 L: dri-devel@lists.freedesktop.org
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH 16/17] iommu: remove DOMAIN_ATTR_IO_PGTABLE_CFG

[Will Deacon]

On Wed, Mar 10, 2021 at 09:58:06AM +0100, Christoph Hellwig wrote:
> On Fri, Mar 05, 2021 at 10:00:12AM +, Will Deacon wrote:
> > > But one thing I'm not sure about is whether
> > > IO_PGTABLE_QUIRK_ARM_OUTER_WBWA is something that other devices
> > > *should* be using as well, but just haven't gotten around to yet.
> > 
> > The intention is certainly that this would be a place to collate per-domain
> > pgtable quirks, so I'd prefer not to tie that to the GPU.
> 
> So the overall consensus is to just keep this as-is for now?

Yes, please. If it doesn't see wider adoption then we can revisit it.

Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 3/3] drm: Add GUD USB Display driver

[Noralf Trønnes]

Den 10.03.2021 05.55, skrev Peter Stuge:
> Noralf Trønnes wrote:
>>> Depending on how long it takes for the DMA mask dependency patch to show
>>> up in drm-misc-next, I will either publish a new version or apply the
>>> current and provide patches with the necessary fixes. 
>>
>> In case I apply this version, are you happy enough with it that you want
>> to give an ack or r-b?
> 
> I've now tested R1 and RGB111 and I think I've found two more things:
> 
> I didn't receive the expected bits/bytes for RGB111 on the bulk endpoint,
> I think because of how components were extracted in gud_xrgb_to_color().
> 
> Changing to the following gets me the expected (X R1 G1 B1 X R2 G2 B2) bytes:
> 
>   r = (*pix32 >> 8) & 0xff;
>   g = (*pix32 >> 16) & 0xff;
>   b = (*pix32++ >> 24) & 0xff;
> 

We're accessing the whole word here through pix32, no byte access, so
endianess doesn't come into play. This change will flip r and b, which
gives: XRGB -> XBGR

BGR is a common thing on controllers, are you sure yours are set to RGB
and not BGR?

And the 0xff masking isn't necessary since we're assigning to a byte, right?

I haven't got a native R1G1B1 display so I have emulated and I do get
the expected colors. This is the conversion function I use on the device
which I think is correct:

static size_t rgb111_to_rgb565(uint16_t *dst, uint8_t *src,
   uint16_t src_width, uint16_t src_height)
{
uint8_t rgb111, val = 0;
size_t len = 0;

for (uint16_t y = 0; y < src_height; y++) {
for (uint16_t x = 0; x < src_width; x++) {
if (!(x % 2))
val = *src++;
rgb111 = val >> 4;
*dst++ = ((rgb111 & 0x04) << 13) | ((rgb111 & 0x02) << 9) |
 ((rgb111 & 0x01) << 4);
len += sizeof(*dst);
val <<= 4;
}
}

   return len;
}

> 
> Then, gud_xrgb_to_color() and maybe even gud_xrgb_to_r124() seem
> to be host endian dependent, at least because of that pix32, but maybe more?
> I don't know whether drm guarantees "native" XRGB byte sequence in memory,
> then I guess the pix32 is okay? Please take a look?
> 
> 
> Finally my very last ask: Please consider renaming GUD_PIXEL_FORMAT_RGB111
> to GUD_PIXEL_FORMAT_XRGB?
> 

It has crossed my mind, I'll change it.

Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: writeback: Use simple encoder

[kernel test robot]

Hi Tian,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.12-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Tian-Tao/drm-writeback-Use-simple-encoder/20210310-153629
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
05a59d79793d482f628a31753c671f2e92178a21
config: x86_64-randconfig-m001-20210308 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/3c17eccc7f6b0abfae1af4d6672dfdbae2beb9c0
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Tian-Tao/drm-writeback-Use-simple-encoder/20210310-153629
git checkout 3c17eccc7f6b0abfae1af4d6672dfdbae2beb9c0
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   ld: drivers/gpu/drm/drm_writeback.o: in function 
`drm_writeback_connector_init':
>> drivers/gpu/drm/drm_writeback.c:190: undefined reference to 
>> `drm_simple_encoder_init'


vim +190 drivers/gpu/drm/drm_writeback.c

   148  
   149  /**
   150   * drm_writeback_connector_init - Initialize a writeback connector and 
its properties
   151   * @dev: DRM device
   152   * @wb_connector: Writeback connector to initialize
   153   * @con_funcs: Connector funcs vtable
   154   * @enc_helper_funcs: Encoder helper funcs vtable to be used by the 
internal encoder
   155   * @formats: Array of supported pixel formats for the writeback engine
   156   * @n_formats: Length of the formats array
   157   *
   158   * This function creates the writeback-connector-specific properties if 
they
   159   * have not been already created, initializes the connector as
   160   * type DRM_MODE_CONNECTOR_WRITEBACK, and correctly initializes the 
property
   161   * values. It will also create an internal encoder associated with the
   162   * drm_writeback_connector and set it to use the @enc_helper_funcs 
vtable for
   163   * the encoder helper.
   164   *
   165   * Drivers should always use this function instead of 
drm_connector_init() to
   166   * set up writeback connectors.
   167   *
   168   * Returns: 0 on success, or a negative error code
   169   */
   170  int drm_writeback_connector_init(struct drm_device *dev,
   171   struct drm_writeback_connector 
*wb_connector,
   172   const struct drm_connector_funcs 
*con_funcs,
   173   const struct drm_encoder_helper_funcs 
*enc_helper_funcs,
   174   const u32 *formats, int n_formats)
   175  {
   176  struct drm_property_blob *blob;
   177  struct drm_connector *connector = &wb_connector->base;
   178  struct drm_mode_config *config = &dev->mode_config;
   179  int ret = create_writeback_properties(dev);
   180  
   181  if (ret != 0)
   182  return ret;
   183  
   184  blob = drm_property_create_blob(dev, n_formats * 
sizeof(*formats),
   185  formats);
   186  if (IS_ERR(blob))
   187  return PTR_ERR(blob);
   188  
   189  drm_encoder_helper_add(&wb_connector->encoder, 
enc_helper_funcs);
 > 190  ret = drm_simple_encoder_init(dev, &wb_connector->encoder,
   191DRM_MODE_ENCODER_VIRTUAL);
   192  if (ret)
   193  goto fail;
   194  
   195  connector->interlace_allowed = 0;
   196  
   197  ret = drm_connector_init(dev, connector, con_funcs,
   198   DRM_MODE_CONNECTOR_WRITEBACK);
   199  if (ret)
   200  goto connector_fail;
   201  
   202  ret = drm_connector_attach_encoder(connector,
   203  &wb_connector->encoder);
   204  if (ret)
   205  goto attach_fail;
   206  
   207  INIT_LIST_HEAD(&wb_connector->job_queue);
   208  spin_lock_init(&wb_connector->job_lock);
   209  
   210  wb_connector->fence_context = dma_fence_context_alloc(1);
   211  spin_lock_init(&wb_connector->fence_lock);
   212  snprintf(wb_connector->timeline_name,
   213   sizeof(wb_connector->timeline_name),
   214   "CONNECTOR:%d-%s", connector->base.id, 
connector->name);
   215  
   216  drm_object_attac

Re: [PATCH v5 12/14] drm/bridge: imx: Add LDB support for i.MX8qxp

[kernel test robot]

Hi Liu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on robh/for-next drm-intel/for-linux-next 
drm-tip/drm-tip tegra-drm/drm/tegra/for-next linus/master 
drm-exynos/exynos-drm-next v5.12-rc2 next-20210310]
[cannot apply to drm/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/0day-ci/linux/commits/Liu-Ying/Add-some-DRM-bridge-drivers-support-for-i-MX8qm-qxp-SoCs/20210310-181047
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git 
for-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/e621f277f533f302da23441f28b3fc02a152a7df
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Liu-Ying/Add-some-DRM-bridge-drivers-support-for-i-MX8qm-qxp-SoCs/20210310-181047
git checkout e621f277f533f302da23441f28b3fc02a152a7df
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

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

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:16: warning: 'struct 
>> phy_configure_opts_lvds' declared inside parameter list will not be visible 
>> outside of this definition or declaration
  65 | struct phy_configure_opts_lvds *phy_cfg)
 |^~~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_set_phy_cfg':
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:67:9: error: dereferencing 
pointer to incomplete type 'struct phy_configure_opts_lvds'
  67 |  phy_cfg->bits_per_lane_and_dclk_cycle = 7;
 | ^~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_bridge_atomic_check':
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:94:49: error: 'union 
phy_configure_opts' has no member named 'lvds'
  94 |  struct phy_configure_opts_lvds *phy_cfg = &opts.lvds;
 | ^
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:102:57: error: passing argument 
4 of 'imx8qxp_ldb_set_phy_cfg' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 102 |  imx8qxp_ldb_set_phy_cfg(imx8qxp_ldb, di_clk, is_split, phy_cfg);
 | ^~~
 | |
 | struct 
phy_configure_opts_lvds *
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:41: note: expected 'struct 
phy_configure_opts_lvds *' but argument is of type 'struct 
phy_configure_opts_lvds *'
  65 | struct phy_configure_opts_lvds *phy_cfg)
 | ^~~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_bridge_mode_set':
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:136:49: error: 'union 
phy_configure_opts' has no member named 'lvds'
 136 |  struct phy_configure_opts_lvds *phy_cfg = &opts.lvds;
 | ^
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:162:57: error: passing argument 
4 of 'imx8qxp_ldb_set_phy_cfg' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 162 |  imx8qxp_ldb_set_phy_cfg(imx8qxp_ldb, di_clk, is_split, phy_cfg);
 | ^~~
 | |
 | struct 
phy_configure_opts_lvds *
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:41: note: expected 'struct 
phy_configure_opts_lvds *' but argument is of type 'struct 
phy_configure_opts_lvds *'
  65 | struct phy_configure_opts_lvds *phy_cfg)
 | ^~~
   cc1: some warnings being treated as errors


vim +65 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c

62  
63  static void imx8qxp_ldb_set_phy_cfg(struct imx8qxp_ldb *imx8qxp_ldb,
64  unsigned long di_clk, bool is_split,
  > 65  

Re: [PATCH] drm/gem: add checks of drm_gem_object->funcs

[Pavel Turinský]

On 08. 03. 21 20:20, Alex Deucher wrote:
> Should be fixed here:
> https://patchwork.freedesktop.org/patch/423250/
> 
> Alex

Thanks, it works for me! I tried only the first patch from the series,
the rest didn't look relevant to me. I can try that too.

I didn't test it thoroughly (I don't know how), but the issue with being
unable to start X.org is gone now and the kernel doesn't complain.

Pavel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 02/14] media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner

[Laurent Pinchart]

Hi Liu,

Thank you for the patch.

On Wed, Mar 10, 2021 at 05:55:26PM +0800, Liu Ying wrote:
> This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
> RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp
> pixel combiner.  The RGB pixels with padding low per component are
> transmitted on a 30-bit input bus(10-bit per component) from a display
> controller or a 36-bit output bus(12-bit per component) to a pixel link.
> 
> Reviewed-by: Robert Foss 
> Signed-off-by: Liu Ying 
> ---
> v4->v5:
> * Add Robert's R-b tag.
> 
> v3->v4:
> * No change.
> 
> v2->v3:
> * No change.
> 
> v1->v2:
> * No change.
> 
>  .../userspace-api/media/v4l/subdev-formats.rst | 156 
> +
>  1 file changed, 156 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst 
> b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> index 7f16cbe..201c16d 100644
> --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
> +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> @@ -1488,6 +1488,80 @@ The following tables list existing packed RGB formats.
>- b\ :sub:`2`
>- b\ :sub:`1`
>- b\ :sub:`0`
> +* .. _MEDIA-BUS-FMT-RGB666-1X30-CPADLO:
> +
> +  - MEDIA_BUS_FMT_RGB666_1X30-CPADLO
> +  - 0x101e
> +  -
> +  - 0
> +  - 0

I count 32 bits here. Should these two 0 be replaced by spaces ? Same
for MEDIA_BUS_FMT_RGB888_1X30-CPADLO.

With this fixed,

Reviewed-by: Laurent Pinchart 

> +  - r\ :sub:`5`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - g\ :sub:`5`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - b\ :sub:`5`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +* .. _MEDIA-BUS-FMT-RGB888-1X30-CPADLO:
> +
> +  - MEDIA_BUS_FMT_RGB888_1X30-CPADLO
> +  - 0x101f
> +  -
> +  - 0
> +  - 0
> +  - r\ :sub:`7`
> +  - r\ :sub:`6`
> +  - r\ :sub:`5`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - 0
> +  - 0
> +  - g\ :sub:`7`
> +  - g\ :sub:`6`
> +  - g\ :sub:`5`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - 0
> +  - 0
> +  - b\ :sub:`7`
> +  - b\ :sub:`6`
> +  - b\ :sub:`5`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - 0
> +  - 0
>  * .. _MEDIA-BUS-FMT-ARGB888-1X32:
>  
>- MEDIA_BUS_FMT_ARGB888_1X32
> @@ -1665,6 +1739,88 @@ The following table list existing packed 36bit wide 
> RGB formats.
>- 2
>- 1
>- 0
> +* .. _MEDIA-BUS-FMT-RGB666-1X36-CPADLO:
> +
> +  - MEDIA_BUS_FMT_RGB666_1X36_CPADLO
> +  - 0x1020
> +  -
> +  - r\ :sub:`5`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - g\ :sub:`5`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - b\ :sub:`5`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +* .. _MEDIA-BUS-FMT-RGB888-1X36-CPADLO:
> +
> +  - MEDIA_BUS_FMT_RGB888_1X36_CPADLO
> +  - 0x1021
> +  -
> +  - r\ :sub:`7`
> +  - r\ :sub:`6`
> +  - r\ :sub:`5`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - g\ :sub:`7`
> +  - g\ :sub:`6`
> +  - g\ :sub:`5`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
> +  - b\ :sub:`7`
> +  - b\ :sub:`6`
> +  - b\ :sub:`5`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +  - 0
> +  - 0
> +  - 0
> +  - 0
>  * .. _MEDIA-BUS-FMT-RGB121212-1X36:
>  
>- MEDIA_BUS_FMT_RGB121212_1X36

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 13/14] drm/bridge: imx: Add LDB support for i.MX8qm

[kernel test robot]

Hi Liu,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on shawnguo/for-next]
[also build test WARNING on robh/for-next drm-intel/for-linux-next 
drm-tip/drm-tip tegra-drm/drm/tegra/for-next linus/master 
drm-exynos/exynos-drm-next v5.12-rc2 next-20210310]
[cannot apply to drm/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/0day-ci/linux/commits/Liu-Ying/Add-some-DRM-bridge-drivers-support-for-i-MX8qm-qxp-SoCs/20210310-181047
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git 
for-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/2018fd6af385c7cad1ce9510fca71cc87d6d151b
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Liu-Ying/Add-some-DRM-bridge-drivers-support-for-i-MX8qm-qxp-SoCs/20210310-181047
git checkout 2018fd6af385c7cad1ce9510fca71cc87d6d151b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

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

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:69:15: warning: 'struct 
>> phy_configure_opts_lvds' declared inside parameter list will not be visible 
>> outside of this definition or declaration
  69 |struct phy_configure_opts_lvds *phy_cfg)
 |   ^~~
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c: In function 
'imx8qm_ldb_set_phy_cfg':
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:71:9: error: dereferencing 
pointer to incomplete type 'struct phy_configure_opts_lvds'
  71 |  phy_cfg->bits_per_lane_and_dclk_cycle = 7;
 | ^~
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c: In function 
'imx8qm_ldb_bridge_atomic_check':
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:91:49: error: 'union 
phy_configure_opts' has no member named 'lvds'
  91 |  struct phy_configure_opts_lvds *phy_cfg = &opts.lvds;
 | ^
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:99:62: error: passing argument 5 
of 'imx8qm_ldb_set_phy_cfg' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  99 |  imx8qm_ldb_set_phy_cfg(imx8qm_ldb, di_clk, is_split, false, 
phy_cfg);
 |  ^~~
 |  |
 |  struct 
phy_configure_opts_lvds *
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:69:40: note: expected 'struct 
phy_configure_opts_lvds *' but argument is of type 'struct 
phy_configure_opts_lvds *'
  69 |struct phy_configure_opts_lvds *phy_cfg)
 |^~~
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:111:10: error: passing argument 
5 of 'imx8qm_ldb_set_phy_cfg' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 111 |  phy_cfg);
 |  ^~~
 |  |
 |  struct phy_configure_opts_lvds *
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:69:40: note: expected 'struct 
phy_configure_opts_lvds *' but argument is of type 'struct 
phy_configure_opts_lvds *'
  69 |struct phy_configure_opts_lvds *phy_cfg)
 |^~~
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c: In function 
'imx8qm_ldb_bridge_mode_set':
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:137:49: error: 'union 
phy_configure_opts' has no member named 'lvds'
 137 |  struct phy_configure_opts_lvds *phy_cfg = &opts.lvds;
 | ^
   drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c:152:62: error: passing argument 
5 of 'imx8qm_ldb_set_phy_cfg' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 152 |  imx8qm_ldb_set_phy_cfg(imx8qm_ldb, di_clk, is_split, false, 
phy_cfg);
 |  ^~~
 |  |
 |  struct 
phy_config

Re: [PATCH v5 01/14] media: uapi: Add some RGB bus formats for i.MX8qm/qxp pixel combiner

[Laurent Pinchart]

Hi Liu,

Thank you for the patch.

On Wed, Mar 10, 2021 at 05:55:25PM +0800, Liu Ying wrote:
> This patch adds RGB666_1X30_CPADLO, RGB888_1X30_CPADLO, RGB666_1X36_CPADLO
> and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp pixel combiner.
> The RGB pixels with padding low per component are transmitted on a 30-bit
> input bus(10-bit per component) from a display controller or a 36-bit
> output bus(12-bit per component) to a pixel link.
> 
> Reviewed-by: Robert Foss 
> Signed-off-by: Liu Ying 

Reviewed-by: Laurent Pinchart 

> ---
> v4->v5:
> * Add Robert's R-b tag.
> 
> v3->v4:
> * No change.
> 
> v2->v3:
> * No change.
> 
> v1->v2:
> * No change.
> 
>  include/uapi/linux/media-bus-format.h | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/media-bus-format.h 
> b/include/uapi/linux/media-bus-format.h
> index 0dfc11e..ec3323d 100644
> --- a/include/uapi/linux/media-bus-format.h
> +++ b/include/uapi/linux/media-bus-format.h
> @@ -34,7 +34,7 @@
>  
>  #define MEDIA_BUS_FMT_FIXED  0x0001
>  
> -/* RGB - next is 0x101e */
> +/* RGB - next is 0x1022 */
>  #define MEDIA_BUS_FMT_RGB444_1X120x1016
>  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001
>  #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002
> @@ -59,9 +59,13 @@
>  #define MEDIA_BUS_FMT_RGB888_3X8_DELTA   0x101d
>  #define MEDIA_BUS_FMT_RGB888_1X7X4_SPWG  0x1011
>  #define MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA 0x1012
> +#define MEDIA_BUS_FMT_RGB666_1X30_CPADLO 0x101e
> +#define MEDIA_BUS_FMT_RGB888_1X30_CPADLO 0x101f
>  #define MEDIA_BUS_FMT_ARGB_1X32  0x100d
>  #define MEDIA_BUS_FMT_RGB888_1X32_PADHI  0x100f
>  #define MEDIA_BUS_FMT_RGB101010_1X30 0x1018
> +#define MEDIA_BUS_FMT_RGB666_1X36_CPADLO 0x1020
> +#define MEDIA_BUS_FMT_RGB888_1X36_CPADLO 0x1021
>  #define MEDIA_BUS_FMT_RGB121212_1X36 0x1019
>  #define MEDIA_BUS_FMT_RGB161616_1X48 0x101a
>  

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] fb_defio: Remove custom address_space_operations

[Matthew Wilcox (Oracle)]

There's no need to give the page an address_space.  Leaving the
page->mapping as NULL will cause the VM to handle set_page_dirty()
the same way that it's set now, and that was the only reason to
set the address_space in the first place.

Signed-off-by: Matthew Wilcox (Oracle) 
---
 drivers/video/fbdev/core/fb_defio.c | 33 -
 drivers/video/fbdev/core/fbmem.c|  4 
 include/linux/fb.h  |  3 ---
 3 files changed, 40 deletions(-)

diff --git a/drivers/video/fbdev/core/fb_defio.c 
b/drivers/video/fbdev/core/fb_defio.c
index a591d291b231..1bb208b3c4bb 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -52,13 +52,6 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS;
 
get_page(page);
-
-   if (vmf->vma->vm_file)
-   page->mapping = vmf->vma->vm_file->f_mapping;
-   else
-   printk(KERN_ERR "no mapping available\n");
-
-   BUG_ON(!page->mapping);
page->index = vmf->pgoff;
 
vmf->page = page;
@@ -151,17 +144,6 @@ static const struct vm_operations_struct 
fb_deferred_io_vm_ops = {
.page_mkwrite   = fb_deferred_io_mkwrite,
 };
 
-static int fb_deferred_io_set_page_dirty(struct page *page)
-{
-   if (!PageDirty(page))
-   SetPageDirty(page);
-   return 0;
-}
-
-static const struct address_space_operations fb_deferred_io_aops = {
-   .set_page_dirty = fb_deferred_io_set_page_dirty,
-};
-
 int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
 {
vma->vm_ops = &fb_deferred_io_vm_ops;
@@ -212,14 +194,6 @@ void fb_deferred_io_init(struct fb_info *info)
 }
 EXPORT_SYMBOL_GPL(fb_deferred_io_init);
 
-void fb_deferred_io_open(struct fb_info *info,
-struct inode *inode,
-struct file *file)
-{
-   file->f_mapping->a_ops = &fb_deferred_io_aops;
-}
-EXPORT_SYMBOL_GPL(fb_deferred_io_open);
-
 void fb_deferred_io_cleanup(struct fb_info *info)
 {
struct fb_deferred_io *fbdefio = info->fbdefio;
@@ -228,13 +202,6 @@ void fb_deferred_io_cleanup(struct fb_info *info)
 
BUG_ON(!fbdefio);
cancel_delayed_work_sync(&info->deferred_work);
-
-   /* clear out the mapping that we setup */
-   for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
-   page = fb_deferred_io_page(info, i);
-   page->mapping = NULL;
-   }
-
mutex_destroy(&fbdefio->lock);
 }
 EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 06f5805de2de..372b52a2befa 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1415,10 +1415,6 @@ __releases(&info->lock)
if (res)
module_put(info->fbops->owner);
}
-#ifdef CONFIG_FB_DEFERRED_IO
-   if (info->fbdefio)
-   fb_deferred_io_open(info, inode, file);
-#endif
 out:
unlock_fb_info(info);
if (res)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index ecfbcc0553a5..a8dccd23c249 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -659,9 +659,6 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
d_pitch,
 /* drivers/video/fb_defio.c */
 int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
 extern void fb_deferred_io_init(struct fb_info *info);
-extern void fb_deferred_io_open(struct fb_info *info,
-   struct inode *inode,
-   struct file *file);
 extern void fb_deferred_io_cleanup(struct fb_info *info);
 extern int fb_deferred_io_fsync(struct file *file, loff_t start,
loff_t end, int datasync);
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tiny: add support for Waveshare 2inch LCD module

[Carlis]

 addr_mode = ST7789V_MX | ST7789V_MV;
+   break;
+   }
+
+   if (priv->cfg->rgb)
+   addr_mode |= ST7789V_RGB;
+
+   mipi_dbi_command(dbi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+   mipi_dbi_command(dbi, MIPI_DCS_SET_PIXEL_FORMAT,
+MIPI_DCS_PIXEL_FMT_16BIT);
+   mipi_dbi_command(dbi, MIPI_DCS_ENTER_INVERT_MODE);
+   mipi_dbi_command(dbi, ST7789V_PORCTRL, 0x0c, 0x0c, 0x00, 0x33, 0x33);
+   mipi_dbi_command(dbi, ST7789V_GCTRL, 0x35);
+   mipi_dbi_command(dbi, ST7789V_VCOMS, 0x1f);
+   mipi_dbi_command(dbi, ST7789V_LCMCTRL, 0x2c);
+   mipi_dbi_command(dbi, ST7789V_VDVVRHEN, 0x01);
+   mipi_dbi_command(dbi, ST7789V_VRHS, 0x12);
+   mipi_dbi_command(dbi, ST7789V_VDVS, 0x20);
+   mipi_dbi_command(dbi, ST7789V_FRCTRL2, 0x0f);
+   mipi_dbi_command(dbi, ST7789V_PWCTRL1, 0xa4, 0xa1);
+   mipi_dbi_command(dbi, ST7789V_PVGAMCTRL, 0xd0, 0x08, 0x11, 0x08, 0x0c,
+   0x15, 0x39, 0x33, 0x50, 0x36, 0x13, 0x14, 0x29, 
0x2d);
+   mipi_dbi_command(dbi, ST7789V_NVGAMCTRL, 0xd0, 0x08, 0x10, 0x08, 0x06,
+   0x06, 0x39, 0x44, 0x51, 0x0b, 0x16, 0x14, 0x2f, 
0x31);
+   mipi_dbi_command(dbi, MIPI_DCS_SET_DISPLAY_ON);
+   msleep(100);
+   mipi_dbi_enable_flush(dbidev, crtc_state, plane_state);
+
+out_exit:
+   drm_dev_exit(idx);
+}
+
+static const struct drm_simple_display_pipe_funcs st7789v_pipe_funcs = {
+   .enable = st7789v_pipe_enable,
+   .disable= mipi_dbi_pipe_disable,
+   .update = mipi_dbi_pipe_update,
+   .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+};
+
+static const struct st7789v_cfg ws_2inch_lcd_cfg = {
+   .mode   = { DRM_SIMPLE_MODE(240, 320, 34, 43) },
+   /* Cannot read from Waveshare 2inch lcd module" display via SPI */
+   .write_only = true,
+   .rgb= false,
+};
+
+
+DEFINE_DRM_GEM_CMA_FOPS(st7789v_fops);
+
+static const struct drm_driver st7789v_driver = {
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+   .fops   = &st7789v_fops,
+   DRM_GEM_CMA_DRIVER_OPS_VMAP,
+   .debugfs_init   = mipi_dbi_debugfs_init,
+   .name   = "st7789v",
+   .desc   = "Sitronix ST7789R",
+   .date   = "20210310",
+   .major  = 1,
+   .minor  = 0,
+};
+
+static const struct of_device_id st7789v_of_match[] = {
+   { .compatible = "waveshare,ws-2inch-lcd", .data = &ws_2inch_lcd_cfg },
+   { },
+};
+MODULE_DEVICE_TABLE(of, st7789v_of_match);
+
+static const struct spi_device_id st7789v_id[] = {
+   { "ws-2inch-lcd", (uintptr_t)&ws_2inch_lcd_cfg },
+   { },
+};
+MODULE_DEVICE_TABLE(spi, st7789v_id);
+
+static int st7789v_probe(struct spi_device *spi)
+{
+   struct device *dev = &spi->dev;
+   const struct st7789v_cfg *cfg;
+   struct mipi_dbi_dev *dbidev;
+   struct st7789v_priv *priv;
+   struct drm_device *drm;
+   struct mipi_dbi *dbi;
+   struct gpio_desc *dc;
+   u32 rotation = 0;
+   int ret;
+
+   cfg = device_get_match_data(&spi->dev);
+   if (!cfg)
+   cfg = (void *)spi_get_device_id(spi)->driver_data;
+
+   priv = devm_drm_dev_alloc(dev, &st7789v_driver,
+ struct st7789v_priv, dbidev.drm);
+   if (IS_ERR(priv))
+   return PTR_ERR(priv);
+
+   dbidev = &priv->dbidev;
+   priv->cfg = cfg;
+
+   dbi = &dbidev->dbi;
+   drm = &dbidev->drm;
+
+   dbi->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+   if (IS_ERR(dbi->reset)) {
+   DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
+   return PTR_ERR(dbi->reset);
+   }
+
+   dc = devm_gpiod_get(dev, "dc", GPIOD_OUT_LOW);
+   if (IS_ERR(dc)) {
+   DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
+   return PTR_ERR(dc);
+   }
+
+   dbidev->backlight = devm_of_find_backlight(dev);
+   if (IS_ERR(dbidev->backlight))
+   return PTR_ERR(dbidev->backlight);
+
+   device_property_read_u32(dev, "rotation", &rotation);
+
+   ret = mipi_dbi_spi_init(spi, dbi, dc);
+   if (ret)
+   return ret;
+
+   if (cfg->write_only)
+   dbi->read_commands = NULL;
+
+   dbidev->left_offset = cfg->left_offset;
+   dbidev->top_offset = cfg->top_offset;
+
+   ret = mipi_dbi_dev_init(dbidev, &st7789v_pipe_funcs, &cfg->mode,
+   rotation);
+   if (ret)
+   return ret;
+
+   drm_mode_config_reset(dr

[PATCH] dt-bindings: display: sitronix, st7789v: Add Waveshare 2inch LCD module

[Carlis]

From: "Carlis" 

Document support for the Waveshare 2inch LCD module display, which is a
240x320 2" TFT display driven by a Sitronix ST7789V TFT Controller.

Signed-off-by: Carlis 
---
 .../bindings/display/sitronix,st7789v.yaml | 72 ++
 1 file changed, 72 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/sitronix,st7789v.yaml

diff --git a/Documentation/devicetree/bindings/display/sitronix,st7789v.yaml 
b/Documentation/devicetree/bindings/display/sitronix,st7789v.yaml
new file mode 100644
index 000..8a0f21a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/sitronix,st7789v.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/sitronix,st7789v.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sitronix ST7789V Display Panels Device Tree Bindings
+
+maintainers:
+  - Carlis 
+
+description:
+  This binding is for display panels using a Sitronix ST7789V
+  controller in SPI mode.
+
+allOf:
+  - $ref: panel/panel-common.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - description:
+  Waveshare 2" 240x320 Color TFT LCD
+items:
+  - enum:
+  - waveshare,ws-2inch-lcd
+  - const: sitronix,st7789v
+
+  spi-max-frequency:
+maximum: 3200
+
+  dc-gpios:
+maxItems: 1
+description: Display data/command selection (D/CX)
+
+  backlight: true
+  reg: true
+  reset-gpios: true
+  rotation: true
+
+required:
+  - compatible
+  - reg
+  - dc-gpios
+  - reset-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+backlight: backlight {
+compatible = "gpio-backlight";
+gpios = <&gpio 18 GPIO_ACTIVE_HIGH>;
+};
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+display@0{
+compatible = "waveshare,ws-2inch-lcd", "sitronix,st7789v";
+reg = <0>;
+spi-max-frequency = <3200>;
+dc-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>;
+reset-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>;
+rotation = <270>;
+};
+};
+
+...
-- 
1.9.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: Ensure that the modifier requested is supported by plane.

[Mark Yacoub]

From: Mark Yacoub 

On initializing the framebuffer, call drm_any_plane_has_format to do a
check if the modifier is supported. drm_any_plane_has_format calls
dm_plane_format_mod_supported which is extended to validate that the
modifier is on the list of the plane's supported modifiers.

The bug was caught using igt-gpu-tools test: 
kms_addfb_basic.addfb25-bad-modifier

Tested on ChromeOS Zork by turning on the display, running an overlay
test, and running a YT video.

Cc: Alex Deucher 
Cc: Bas Nieuwenhuizen 
Signed-off-by: default avatarMark Yacoub 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   | 13 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  9 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index afa5f8ad0f563..a947b5aa420d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -908,6 +908,19 @@ int amdgpu_display_gem_fb_verify_and_init(
 &amdgpu_fb_funcs);
if (ret)
goto err;
+   /* Verify that the modifier is supported. */
+   if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+   struct drm_format_name_buf format_name;
+   drm_dbg_kms(dev,
+   "unsupported pixel format %s / modifier 0x%llx\n",
+   drm_get_format_name(mode_cmd->pixel_format,
+   &format_name),
+   mode_cmd->modifier[0]);
+
+   ret = -EINVAL;
+   goto err;
+   }
 
ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
if (ret)
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 961abf1cf040c..21314024a83ce 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3939,6 +3939,7 @@ static bool dm_plane_format_mod_supported(struct 
drm_plane *plane,
 {
struct amdgpu_device *adev = drm_to_adev(plane->dev);
const struct drm_format_info *info = drm_format_info(format);
+   int i;
 
enum dm_micro_swizzle microtile = modifier_gfx9_swizzle_mode(modifier) 
& 3;
 
@@ -3952,6 +3953,14 @@ static bool dm_plane_format_mod_supported(struct 
drm_plane *plane,
if (modifier == DRM_FORMAT_MOD_LINEAR)
return true;
 
+   /* Check that the modifier is on the list of the plane's supported 
modifiers. */
+   for (i = 0; i < plane->modifier_count; i++) {
+   if (modifier == plane->modifiers[i])
+   break;
+   }
+   if (i == plane->modifier_count)
+   return false;
+
/*
 * The arbitrary tiling support for multiplane formats has not been 
hooked
 * up.
-- 
2.30.1.766.gb4fecdf3b7-goog

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH]] drm/amdgpu/gfx9: add gfxoff quirk

[Daniel Gomez]

Disabling GFXOFF via the quirk list fixes a hardware lockup in
Ryzen V1605B, RAVEN 0x1002:0x15DD rev 0x83.

Signed-off-by: Daniel Gomez 
---

This patch is a continuation of the work here:
https://lkml.org/lkml/2021/2/3/122 where a hardware lockup was discussed and
a dma_fence deadlock was provoke as a side effect. To reproduce the issue
please refer to the above link.

The hardware lockup was introduced in 5.6-rc1 for our particular revision as it
wasn't part of the new blacklist. Before that, in kernel v5.5, this hardware was
working fine without any hardware lock because the GFXOFF was actually disabled
by the if condition for the CHIP_RAVEN case. So this patch, adds the 'Radeon
Vega Mobile Series [1002:15dd] (rev 83)' to the blacklist to disable the GFXOFF.

But besides the fix, I'd like to ask from where this revision comes from. Is it
an ASIC revision or is it hardcoded in the VBIOS from our vendor? From what I
can see, it comes from the ASIC and I wonder if somehow we can get an APU in the
future, 'not blacklisted', with the same problem. Then, should this table only
filter for the vendor and device and not the revision? Do you know if there are
any revisions for the 1002:15dd validated, tested and functional?

Logs:
[   27.708348] [drm] initializing kernel modesetting (RAVEN
0x1002:0x15DD 0x1002:0x15DD 0x83).
[   27.789156] amdgpu: ATOM BIOS: 113-RAVEN-115

Thanks in advance,
Daniel

 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index 65db88bb6cbc..319d4b99aec8 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -1243,6 +1243,8 @@ static const struct amdgpu_gfxoff_quirk 
amdgpu_gfxoff_quirk_list[] = {
{ 0x1002, 0x15dd, 0x103c, 0x83e7, 0xd3 },
/* GFXOFF is unstable on C6 parts with a VBIOS 113-RAVEN-114 */
{ 0x1002, 0x15dd, 0x1002, 0x15dd, 0xc6 },
+   /* GFXOFF provokes a hw lockup on 83 parts with a VBIOS 113-RAVEN-115 */
+   { 0x1002, 0x15dd, 0x1002, 0x15dd, 0x83 },
{ 0, 0, 0, 0, 0 },
 };

--
2.30.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Is LLVM 13 (git) really ready for testing/development? libclc didn't compile

[Jan Vesely]

One more update. without changing any cmake files the following cmdline
should work:
cmake ../llvm-project/libclc/
-DLLVM_CONFIG=/usr/local/llvm-git/bin/llvm-config
-DCMAKE_LLAsm_FLAGS=-cl-no-stdinc -DCMAKE_CLC_FLAGS=-cl-no-stdinc

Jan
On Wed, Mar 10, 2021 at 1:20 AM Jan Vesely  wrote:

> hi,
>
> sorry the option is actually -cl-no-stdinc. you can add it to
> 'target_compiler_options'.
> I should have a patch ready soon(tm), but time is scarce.
>
> Jan
>
> On Sun, Mar 7, 2021 at 9:51 PM Dieter Nützel  wrote:
>
>> Hello Jan,
>>
>> I very much appreciate your advice.
>> Tried several places...
>> ...where to put it?
>>
>> Dieter
>>
>> Am 06.03.2021 17:56, schrieb Jan Vesely:
>> > Not Marek, but hope this answer will help.
>> > libclc uses clang CLC preprocessor on .ll files, llvm/clang-13 started
>> > including clc declarations by default (clang
>> > cf3ef15a6ec5e5b45c6c54e8fbe3769255e815ce),
>> > thus corrupting any .ll assembly files that are used by libclc.
>> > Inclusion of the default declarations can be turned off using a
>> > cmdline switch but that remains to be implemented in the libclc build
>> > system.
>> > manually adding '-cl-no-stdinc' should work as a workaround.
>> >
>> > Jan
>> >
>> > On Thu, Mar 4, 2021 at 10:27 PM Dieter Nützel 
>> > wrote:
>> >
>> >> Hello Marek,
>> >>
>> >> can't compile anything, here.
>> >> Poor Intel Nehalem X3470.
>> >>
>> >> Trying LLVM 12-rc2 later.
>> >>
>> >> Greetings,
>> >> Dieter
>> >>
>> >> llvm-project/libclc> cd build && cmake ../
>> >> -- The CXX compiler identification is GNU 10.2.1
>> >> -- Detecting CXX compiler ABI info
>> >> -- Detecting CXX compiler ABI info - done
>> >> -- Check for working CXX compiler: /usr/bin/c++ - skipped
>> >> -- Detecting CXX compile features
>> >> -- Detecting CXX compile features - done
>> >> LLVM version: 13.0.0git
>> >> LLVM system libs:
>> >> LLVM libs: -lLLVM-13git
>> >> LLVM libdir: /usr/local/lib
>> >> LLVM bindir: /usr/local/bin
>> >> LLVM ld flags: -L/usr/local/lib
>> >> LLVM cxx flags:
>> >>
>> >
>> -I/usr/local/include;-std=c++14;;;-fno-exceptions;-D_GNU_SOURCE;-D__STDC_CONSTANT_MACROS;-D__STDC_FORMAT_MACROS;-D__STDC_LIMIT_MACROS;-fno-rtti;-fno-exceptions
>> >>
>> >> clang: /usr/local/bin/clang
>> >> llvm-as: /usr/local/bin/llvm-as
>> >> llvm-link: /usr/local/bin/llvm-link
>> >> opt: /usr/local/bin/opt
>> >> llvm-spirv: /usr/local/bin/llvm-spirv
>> >>
>> >> -- Check for working CLC compiler: /usr/local/bin/clang
>> >> -- Check for working CLC compiler: /usr/local/bin/clang -- works
>> >> -- Check for working LLAsm compiler: /usr/local/bin/llvm-as
>> >> -- Check for working LLAsm compiler: /usr/local/bin/llvm-as --
>> >> broken
>> >> CMake Error at cmake/CMakeTestLLAsmCompiler.cmake:40 (message):
>> >> The LLAsm compiler "/usr/local/bin/llvm-as" is not able to
>> >> compile a
>> >> simple
>> >> test program.
>> >>
>> >> It fails with the following output:
>> >>
>> >> Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp
>> >>
>> >> Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast &&
>> >> /usr/bin/gmake
>> >> -f
>> >> CMakeFiles/cmTC_87af9.dir/build.make
>> >> CMakeFiles/cmTC_87af9.dir/build
>> >>
>> >> gmake[1]: Verzeichnis
>> >> „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird
>> >> betreten
>> >>
>> >> Building LLAsm object
>> >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc
>> >>
>> >> /usr/local/bin/clang -E -P -x cl
>> >>
>> >>
>> > /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp/testLLAsmCompiler.ll
>> >>
>> >> -o
>> >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp
>> >>
>> >> /usr/local/bin/llvm-as -o
>> >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc
>> >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp
>> >>
>> >> /usr/local/bin/llvm-as:
>> >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc.temp:1:1: error:
>> >> expected
>> >> top-level entity
>> >>
>> >> typedef unsigned char uchar;
>> >>
>> >> ^
>> >>
>> >> gmake[1]: *** [CMakeFiles/cmTC_87af9.dir/build.make:86:
>> >> CMakeFiles/cmTC_87af9.dir/testLLAsmCompiler.bc] Fehler 1
>> >>
>> >> gmake[1]: Verzeichnis
>> >> „/opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp“ wird
>> >> verlassen
>> >>
>> >> gmake: *** [Makefile:140: cmTC_87af9/fast] Fehler 2
>> >>
>> >> CMake will not be able to correctly generate this project.
>> >> Call Stack (most recent call first):
>> >> CMakeLists.txt:127 (enable_language)
>> >>
>> >> -- Configuring incomplete, errors occurred!
>> >> See also
>> >> "/opt/llvm-project/libclc/build/CMakeFiles/CMakeOutput.log".
>> >> See also "/opt/llvm-project/libclc/build/CMakeFiles/CMakeError.log".
>> >>
>> >> CMakeError.log
>> >> Determining if the LLAsm compiler works failed with the following
>> >> output:
>> >> Change Dir: /opt/llvm-project/libclc/build/CMakeFiles/CMakeTmp
>> >>
>> >> Run Build Command(s):/usr/bin/gmake cmTC_87af9/fast &&
>> >> /usr/bin/gmake
>> >> -f CMakeFiles/cmTC_87af9.dir/build.make
>> >> CMakeFiles/cmTC_87af9.dir/build
>> >> gmake[1]: Verzeichnis
>> >> „/opt/llvm-project/libcl

Re: [PATCH]] drm/amdgpu/gfx9: add gfxoff quirk

[Alex Deucher]

On Wed, Mar 10, 2021 at 11:37 AM Daniel Gomez  wrote:
>
> Disabling GFXOFF via the quirk list fixes a hardware lockup in
> Ryzen V1605B, RAVEN 0x1002:0x15DD rev 0x83.
>
> Signed-off-by: Daniel Gomez 
> ---
>
> This patch is a continuation of the work here:
> https://lkml.org/lkml/2021/2/3/122 where a hardware lockup was discussed and
> a dma_fence deadlock was provoke as a side effect. To reproduce the issue
> please refer to the above link.
>
> The hardware lockup was introduced in 5.6-rc1 for our particular revision as 
> it
> wasn't part of the new blacklist. Before that, in kernel v5.5, this hardware 
> was
> working fine without any hardware lock because the GFXOFF was actually 
> disabled
> by the if condition for the CHIP_RAVEN case. So this patch, adds the 'Radeon
> Vega Mobile Series [1002:15dd] (rev 83)' to the blacklist to disable the 
> GFXOFF.
>
> But besides the fix, I'd like to ask from where this revision comes from. Is 
> it
> an ASIC revision or is it hardcoded in the VBIOS from our vendor? From what I
> can see, it comes from the ASIC and I wonder if somehow we can get an APU in 
> the
> future, 'not blacklisted', with the same problem. Then, should this table only
> filter for the vendor and device and not the revision? Do you know if there 
> are
> any revisions for the 1002:15dd validated, tested and functional?

The pci revision id (RID) is used to specify the specific SKU within a
family.  GFXOFF is supposed to be working on all raven variants.  It
was tested and functional on all reference platforms and any OEM
platforms that launched with Linux support.  There are a lot of
dependencies on sbios in the early raven variants (0x15dd), so it's
likely more of a specific platform issue, but there is not a good way
to detect this so we use the DID/SSID/RID as a proxy.  The newer raven
variants (0x15d8) have much better GFXOFF support since they all
shipped with newer firmware and sbios.

Alex


>
> Logs:
> [   27.708348] [drm] initializing kernel modesetting (RAVEN
> 0x1002:0x15DD 0x1002:0x15DD 0x83).
> [   27.789156] amdgpu: ATOM BIOS: 113-RAVEN-115
>
> Thanks in advance,
> Daniel
>
>  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 65db88bb6cbc..319d4b99aec8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -1243,6 +1243,8 @@ static const struct amdgpu_gfxoff_quirk 
> amdgpu_gfxoff_quirk_list[] = {
> { 0x1002, 0x15dd, 0x103c, 0x83e7, 0xd3 },
> /* GFXOFF is unstable on C6 parts with a VBIOS 113-RAVEN-114 */
> { 0x1002, 0x15dd, 0x1002, 0x15dd, 0xc6 },
> +   /* GFXOFF provokes a hw lockup on 83 parts with a VBIOS 113-RAVEN-115 
> */
> +   { 0x1002, 0x15dd, 0x1002, 0x15dd, 0x83 },
> { 0, 0, 0, 0, 0 },
>  };
>
> --
> 2.30.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/3] drm/amdgpu: Remove in_interrupt() usage.

[Sebastian Andrzej Siewior]

On 2021-02-09 18:43:54 [+0100], Christian König wrote:
> Hi Sebastian,
Hi Christian,

> to be honest I'm thinking about that for quite some time now and I don't
> think that this is possible without a severe rewrite of the driver.
> 
> The problem is simply that we have a lot of functions which deal with
> hardware handling independent of the context. But how registers are accessed
> needs to be different depending if your are in the interrupt handler or not.
> 
> You would need to push the information if we are coming in from the
> interrupt handler through a > 10 function calls.
> 
> I don't think that this is feasible nor good design.

Yeah, that is what I saw and didn't even try.

The possible backtrace (at the bottom of this email) is this a correct
assumption?

Another quick question: You acked my three-patch series. I don't see it
in the next tree as of today. Is there anything for me to do?

> Regards,
> Christian.
> 
> Am 09.02.21 um 17:53 schrieb Sebastian Andrzej Siewior:
> > On 2021-02-09 13:50:31 [+0100], Christian König wrote:
> > > Reviewed-by: Christian König  for the series.
> > Thank you.
> > Any chance you could give me a hand with the remaining three users
> > within the amdgpu driver? I don't know if the in_interrupt() check can
> > be limited to certain callers.
> > What I noticed while tracing v5.10 is this:
> > 
> > | Xorg-2257[007] d... 57261.620043: amdgpu_device_wreg: 
> > 0x699f, 0x1bcf, 0x0100
> > |  => trace_event_raw_event_amdgpu_device_wreg
> > |  => amdgpu_device_wreg.part.0
> > |  => dce110_arm_vert_intr
> > |  => dce110_vblank_set
> > |  => dm_enable_vblank
> > |  => drm_vblank_enable
> > |  => drm_vblank_get
> > |  => drm_wait_vblank_ioctl
> > |  => drm_ioctl_kernel
> > |  => drm_ioctl
> > |  => amdgpu_drm_ioctl
> > |  => __x64_sys_ioctl
> > |  => do_syscall_64
> > |  => entry_SYSCALL_64_after_hwframe
> > 
> > I think that amdgpu_device_wreg() -> amdgpu_kiq_wreg() could be invoked.
> > It doesn't here because amdgpu_sriov_runtime() is false.
> > The trace says `d' which means interrupts are disabled but
> > in_interrupt() will return false in this case (no IRQ/softirq).
> > 
> > Sebastian

Sebastian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/7] drm: add simpledrm driver

[nerdopolis]

On Wednesday, March 10, 2021 4:10:35 AM EST Thomas Zimmermann wrote:
> Hi
> 
> Am 10.03.21 um 03:50 schrieb nerdopolis:
> > On Friday, September 2, 2016 4:22:38 AM EST David Herrmann wrote:
> >> Hey
> >>
> >> On request of Noralf, I picked up the patches and prepared v5. Works fine 
> >> with
> >> Xorg, if configured according to:
> >>  
> >> https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html
> >> If anyone knows how to make Xorg pick it up dynamically without such a 
> >> static
> >> configuration, please let me know.
> >>
> >>
> >>
> > Hi
> > 
> > I am kind of curious as I do have interest in seeing this merged as well.
> 
> Please take a look at [1]. It's not the same driver, but something to 
> the same effect. I know it's been almost a year, but I do work on this 
> and intend to come back with a new version during 2021.
> 
Thanks, I'll try that out
> I currently work on fastboot support for the new driver. But it's a 
> complicated matter and takes time. If there's interest, we could talk 
> about merging what's already there.
> 
> Best regards
> Thomas
> 
> [1] 
> https://lore.kernel.org/dri-devel/20200625120011.16168-1-tzimmerm...@suse.de/
> 
> > 
> > There is an email in this thread from 2018, but when I tried to import an 
> > mbox
> > file from the whole month for August 2018, for some reason, kmail doesn't 
> > see
> > the sender and mailing list recipient in that one, so I will reply to this 
> > one,
> > because I was able to import this into my mail client.
> > https://www.spinics.net/lists/dri-devel/msg185519.html
> > 
> > I was able to get this to build against Linux 4.8, but not against a newer
> > version, some headers seem to have been split, and some things are off by 8
> > and other things. I could NOT find a git repo, but I was able to find the
> > newest patches I could find, and import those with git am against 4.8 with
> > some tweaks. If that is needed, I can link it, but only if you want.
> > 
> > However in QEMU I wasn't able to figure out how to make it create a
> > /dev/dri/card0 device, even after blacklisting the other modules for qxl,
> > cirrus, etc, and then modprobe-ing simpledrm
> > 
> > In my view something like this is would be useful. There still could be
> > hardware devices that don't have modesetting support (like vmvga in
> > qemu/virt-manager as an example). And most wayland servers need a
> > /dev/dri/card0 device as well as a potential user-mode TTY replacement would
> > also need /dev/dri/card0
> > 
> > I will admit I unfortunately failed to get it to build against master. I
> > couldn't figure out some of the changes, where some new structs were off by
> > a factor of 8.
> > 
> > 
> > Thanks
> > 
> > 
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> 
> 




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dri-devel Digest, Vol 132, Issue 197

[chatzem]

Qa

Sent from ProtonMail mobile

 Original Message 
On Mar 10, 2021, 12:10, wrote:

> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dri-devel digest..."
>
> Today's Topics:
>
> 1. [PATCH v5 12/14] drm/bridge: imx: Add LDB support for
> i.MX8qxp (Liu Ying)
>
> --
>
> Message: 1
> Date: Wed, 10 Mar 2021 17:55:36 +0800
> From: Liu Ying 
> To: dri-devel@lists.freedesktop.org, devicet...@vger.kernel.org,
> linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org,
> linux-me...@vger.kernel.org
> Cc: airl...@linux.ie, dan...@ffwll.ch, robh...@kernel.org,
> shawn...@kernel.org, s.ha...@pengutronix.de, ker...@pengutronix.de,
> feste...@gmail.com, linux-...@nxp.com, mche...@kernel.org,
> a.ha...@samsung.com, narmstr...@baylibre.com,
> laurent.pinch...@ideasonboard.com, jo...@kwiboo.se,
> jernej.skra...@siol.net, kis...@ti.com, vk...@kernel.org,
> robert.f...@linaro.org, lee.jo...@linaro.org
> Subject: [PATCH v5 12/14] drm/bridge: imx: Add LDB support for
> i.MX8qxp
> Message-ID: <1615370138-5673-13-git-send-email-victor@nxp.com>
> Content-Type: text/plain
>
> This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
> which is officially named as pixel mapper. The LDB has two channels.
> Each of them supports up to 24bpp parallel input color format and can map
> the input to VESA or JEIDA standards. The two channels cannot be used
> simultaneously, that is to say, the user should pick one of them to use.
> Two LDB channels from two LDB instances can work together in LDB split
> mode to support a dual link LVDS display. The channel indexes have to be
> different. Channel0 outputs odd pixels and channel1 outputs even pixels.
> This patch supports the LDB single mode and split mode.
>
> Signed-off-by: Liu Ying 
> ---
> Note that this patch depends on the patch 'phy: Add LVDS configuration 
> options',
> which has already been sent with the following series to add Mixel combo PHY
> found in i.MX8qxp:
> https://www.spinics.net/lists/arm-kernel/msg879957.html
>
> v4->v5:
> * Link with the imx-ldb-helper object. (Robert)
> * Correspondingly, rename 'imx8qxp-ldb.c' to 'imx8qxp-ldb-drv.c'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Drop unnecessary DT validation.
> * Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
> get the input remote endpoint in imx8qxp_ldb_set_di_id().
> * Avoid using companion_port OF node after putting it in
> imx8qxp_ldb_parse_dt_companion().
> * Mention i.MX8qxp LDB official name 'pixel mapper' in the bridge driver
> and Kconfig help message.
>
> drivers/gpu/drm/bridge/imx/Kconfig | 9 +
> drivers/gpu/drm/bridge/imx/Makefile | 3 +
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 720 +++
> 3 files changed, 732 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 1ea1ce7..94f8db4d 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -1,3 +1,12 @@
> +config DRM_IMX8QXP_LDB
> + tristate "Freescale i.MX8QXP LVDS display bridge"
> + depends on OF
> + depends on COMMON_CLK
> + select DRM_KMS_HELPER
> + help
> + Choose this to enable the internal LVDS Display Bridge(LDB) found in
> + Freescale i.MX8qxp processor. Official name of LDB is pixel mapper.
> +
> config DRM_IMX8QXP_PIXEL_COMBINER
> tristate "Freescale i.MX8QM/QXP pixel combiner"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
> b/drivers/gpu/drm/bridge/imx/Makefile
> index e74dd64..96d5d1e 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,3 +1,6 @@
> +imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
> +obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
> +
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c 
> b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> new file mode 100644
> index ..d7f59c1
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> @@ -0,0 +1,720 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

Re: dri-devel Digest, Vol 132, Issue 197

[chatzem]

Sent from ProtonMail mobile

 Original Message 
On Mar 10, 2021, 12:10, wrote:

> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dri-devel digest..."
>
> Today's Topics:
>
> 1. [PATCH v5 12/14] drm/bridge: imx: Add LDB support for
> i.MX8qxp (Liu Ying)
>
> --
>
> Message: 1
> Date: Wed, 10 Mar 2021 17:55:36 +0800
> From: Liu Ying 
> To: dri-devel@lists.freedesktop.org, devicet...@vger.kernel.org,
> linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org,
> linux-me...@vger.kernel.org
> Cc: airl...@linux.ie, dan...@ffwll.ch, robh...@kernel.org,
> shawn...@kernel.org, s.ha...@pengutronix.de, ker...@pengutronix.de,
> feste...@gmail.com, linux-...@nxp.com, mche...@kernel.org,
> a.ha...@samsung.com, narmstr...@baylibre.com,
> laurent.pinch...@ideasonboard.com, jo...@kwiboo.se,
> jernej.skra...@siol.net, kis...@ti.com, vk...@kernel.org,
> robert.f...@linaro.org, lee.jo...@linaro.org
> Subject: [PATCH v5 12/14] drm/bridge: imx: Add LDB support for
> i.MX8qxp
> Message-ID: <1615370138-5673-13-git-send-email-victor@nxp.com>
> Content-Type: text/plain
>
> This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
> which is officially named as pixel mapper. The LDB has two channels.
> Each of them supports up to 24bpp parallel input color format and can map
> the input to VESA or JEIDA standards. The two channels cannot be used
> simultaneously, that is to say, the user should pick one of them to use.
> Two LDB channels from two LDB instances can work together in LDB split
> mode to support a dual link LVDS display. The channel indexes have to be
> different. Channel0 outputs odd pixels and channel1 outputs even pixels.
> This patch supports the LDB single mode and split mode.
>
> Signed-off-by: Liu Ying 
> ---
> Note that this patch depends on the patch 'phy: Add LVDS configuration 
> options',
> which has already been sent with the following series to add Mixel combo PHY
> found in i.MX8qxp:
> https://www.spinics.net/lists/arm-kernel/msg879957.html
>
> v4->v5:
> * Link with the imx-ldb-helper object. (Robert)
> * Correspondingly, rename 'imx8qxp-ldb.c' to 'imx8qxp-ldb-drv.c'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Drop unnecessary DT validation.
> * Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
> get the input remote endpoint in imx8qxp_ldb_set_di_id().
> * Avoid using companion_port OF node after putting it in
> imx8qxp_ldb_parse_dt_companion().
> * Mention i.MX8qxp LDB official name 'pixel mapper' in the bridge driver
> and Kconfig help message.
>
> drivers/gpu/drm/bridge/imx/Kconfig | 9 +
> drivers/gpu/drm/bridge/imx/Makefile | 3 +
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 720 +++
> 3 files changed, 732 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 1ea1ce7..94f8db4d 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -1,3 +1,12 @@
> +config DRM_IMX8QXP_LDB
> + tristate "Freescale i.MX8QXP LVDS display bridge"
> + depends on OF
> + depends on COMMON_CLK
> + select DRM_KMS_HELPER
> + help
> + Choose this to enable the internal LVDS Display Bridge(LDB) found in
> + Freescale i.MX8qxp processor. Official name of LDB is pixel mapper.
> +
> config DRM_IMX8QXP_PIXEL_COMBINER
> tristate "Freescale i.MX8QM/QXP pixel combiner"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
> b/drivers/gpu/drm/bridge/imx/Makefile
> index e74dd64..96d5d1e 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,3 +1,6 @@
> +imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
> +obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
> +
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c 
> b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> new file mode 100644
> index ..d7f59c1
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> @@ -0,0 +1,720 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#in

Re: dri-devel Digest, Vol 132, Issue 197

[chatzem]

Sent from ProtonMail mobile

 Original Message 
On Mar 10, 2021, 12:10, wrote:

> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dri-devel digest..."
>
> Today's Topics:
>
> 1. [PATCH v5 12/14] drm/bridge: imx: Add LDB support for
> i.MX8qxp (Liu Ying)
>
> --
>
> Message: 1
> Date: Wed, 10 Mar 2021 17:55:36 +0800
> From: Liu Ying 
> To: dri-devel@lists.freedesktop.org, devicet...@vger.kernel.org,
> linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org,
> linux-me...@vger.kernel.org
> Cc: airl...@linux.ie, dan...@ffwll.ch, robh...@kernel.org,
> shawn...@kernel.org, s.ha...@pengutronix.de, ker...@pengutronix.de,
> feste...@gmail.com, linux-...@nxp.com, mche...@kernel.org,
> a.ha...@samsung.com, narmstr...@baylibre.com,
> laurent.pinch...@ideasonboard.com, jo...@kwiboo.se,
> jernej.skra...@siol.net, kis...@ti.com, vk...@kernel.org,
> robert.f...@linaro.org, lee.jo...@linaro.org
> Subject: [PATCH v5 12/14] drm/bridge: imx: Add LDB support for
> i.MX8qxp
> Message-ID: <1615370138-5673-13-git-send-email-victor@nxp.com>
> Content-Type: text/plain
>
> This patch adds a drm bridge driver for i.MX8qxp LVDS display bridge(LDB)
> which is officially named as pixel mapper. The LDB has two channels.
> Each of them supports up to 24bpp parallel input color format and can map
> the input to VESA or JEIDA standards. The two channels cannot be used
> simultaneously, that is to say, the user should pick one of them to use.
> Two LDB channels from two LDB instances can work together in LDB split
> mode to support a dual link LVDS display. The channel indexes have to be
> different. Channel0 outputs odd pixels and channel1 outputs even pixels.
> This patch supports the LDB single mode and split mode.
>
> Signed-off-by: Liu Ying 
> ---
> Note that this patch depends on the patch 'phy: Add LVDS configuration 
> options',
> which has already been sent with the following series to add Mixel combo PHY
> found in i.MX8qxp:
> https://www.spinics.net/lists/arm-kernel/msg879957.html
>
> v4->v5:
> * Link with the imx-ldb-helper object. (Robert)
> * Correspondingly, rename 'imx8qxp-ldb.c' to 'imx8qxp-ldb-drv.c'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Drop unnecessary DT validation.
> * Use of_graph_get_endpoint_by_regs() and of_graph_get_remote_endpoint() to
> get the input remote endpoint in imx8qxp_ldb_set_di_id().
> * Avoid using companion_port OF node after putting it in
> imx8qxp_ldb_parse_dt_companion().
> * Mention i.MX8qxp LDB official name 'pixel mapper' in the bridge driver
> and Kconfig help message.
>
> drivers/gpu/drm/bridge/imx/Kconfig | 9 +
> drivers/gpu/drm/bridge/imx/Makefile | 3 +
> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c | 720 +++
> 3 files changed, 732 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 1ea1ce7..94f8db4d 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -1,3 +1,12 @@
> +config DRM_IMX8QXP_LDB
> + tristate "Freescale i.MX8QXP LVDS display bridge"
> + depends on OF
> + depends on COMMON_CLK
> + select DRM_KMS_HELPER
> + help
> + Choose this to enable the internal LVDS Display Bridge(LDB) found in
> + Freescale i.MX8qxp processor. Official name of LDB is pixel mapper.
> +
> config DRM_IMX8QXP_PIXEL_COMBINER
> tristate "Freescale i.MX8QM/QXP pixel combiner"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
> b/drivers/gpu/drm/bridge/imx/Makefile
> index e74dd64..96d5d1e 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,3 +1,6 @@
> +imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
> +obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
> +
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK) += imx8qxp-pixel-link.o
> obj-$(CONFIG_DRM_IMX8QXP_PIXEL_LINK_TO_DPI) += imx8qxp-pxl2dpi.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c 
> b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> new file mode 100644
> index ..d7f59c1
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c
> @@ -0,0 +1,720 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#in

Re: dri-devel Digest, Vol 132, Issue 206

[chatzem]

> + struct ldb_channel *ldb_ch = &imx8qxp_ldb_ch->base;
>> + struct ldb_channel *companion_ldb_ch;
>> + struct device_node *companion;
>> + struct device_node *child;
>> + struct device_node *companion_port = NULL;
>> + struct device_node *port1, *port2;
>> + struct device *dev = imx8qxp_ldb->dev;
>> + const struct of_device_id *match;
>> + u32 i;
>> + int dual_link;
>> + int ret;
>> +
>> + /* Locate the companion LDB for dual-link operation, if any. */
>> + companion = of_parse_phandle(dev->of_node, "fsl,companion-ldb", 0);
>> + if (!companion)
>> + return 0;
>> +
>> + if (!of_device_is_available(companion)) {
>> + DRM_DEV_ERROR(dev, "companion LDB is not available\n");
>> + ret = -ENODEV;
>> + goto out;
>> + }
>> +
>> + /*
>> + * Sanity check: the companion bridge must have the same compatible
>> + * string.
>> + */
>> + match = of_match_device(dev->driver->of_match_table, dev);
>> + if (!of_device_is_compatible(companion, match->compatible)) {
>> + DRM_DEV_ERROR(dev, "companion LDB is incompatible\n");
>> + ret = -ENXIO;
>> + goto out;
>> + }
>> +
>> + for_each_available_child_of_node(companion, child) {
>> + ret = of_property_read_u32(child, "reg", &i);
>> + if (ret || i > MAX_LDB_CHAN_NUM - 1) {
>> + DRM_DEV_ERROR(dev,
>> + "invalid channel node address: %u\n", i);
>> + ret = -EINVAL;
>> + of_node_put(child);
>> + goto out;
>> + }
>> +
>> + /*
>> + * Channel numbers have to be different, because channel0
>> + * transmits odd pixels and channel1 transmits even pixels.
>> + */
>> + if (i == (ldb_ch->chno ^ 0x1)) {
>> + companion_port = child;
>> + break;
>> + }
>> + }
>> +
>> + if (companion_port == NULL) {
>> + DRM_DEV_ERROR(dev,
>> + "failed to find companion LDB channel port\n");
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> +
>> + /*
>> + * We need to work out if the sink is expecting us to function in
>> + * dual-link mode. We do this by looking at the DT port nodes we are
>> + * connected to. If they are marked as expecting odd pixels and
>> + * even pixels than we need to enable LDB split mode.
>> + */
>> + port1 = of_graph_get_port_by_id(ldb_ch->np, 1);
>> + port2 = of_graph_get_port_by_id(companion_port, 1);
>> + dual_link = drm_of_lvds_get_dual_link_pixel_order(port1, port2);
>> + of_node_put(port1);
>> + of_node_put(port2);
>> +
>> + switch (dual_link) {
>> + case DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS:
>> + ldb_ch->link_type = LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
>> + break;
>> + case DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS:
>> + ldb_ch->link_type = LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS;
>> + break;
>> + default:
>> + ret = dual_link;
>> + DRM_DEV_ERROR(dev,
>> + "failed to get dual link pixel order: %d\n", ret);
>> + goto out;
>> + }
>> +
>> + ret = imx8qxp_ldb_check_chno_and_dual_link(ldb_ch, dual_link);
>> + if (ret < 0) {
>> + DRM_DEV_ERROR(dev,
>> + "unmatched channel number(%u) vs dual link(%d)\n",
>> + ldb_ch->chno, dual_link);
>> + goto out;
>> + }
>> +
>> + imx8qxp_ldb->companion = of_drm_find_bridge(companion_port);
>> + if (!imx8qxp_ldb->companion) {
>> + ret = -EPROBE_DEFER;
>> + DRM_DEV_DEBUG_DRIVER(dev,
>> + "failed to find bridge for companion bridge: %d\n", ret);
>> + goto out;
>> + }
>> +
>> + DRM_DEV_DEBUG_DRIVER(dev,
>> + "dual-link configuration detected (companion bridge %pOF)\n",
>> + companion);
>> +
>> + companion_ldb_ch = bridge_to_ldb_ch(imx8qxp_ldb->companion);
>> + companion_ldb_ch->link_type = ldb_ch->link_type;
>> +out:
>> + of_node_put(companion_port);
>> + of_node_put(companion);
>> + return ret;
>> +}
>> +
>> +static int imx8qxp_ldb_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct imx8qxp_ldb *imx8qxp_ldb;
>> + struct imx8qxp_ldb_channel *imx8qxp_ldb_ch;
>> + struct ldb *ldb;
>> + struct ldb_channel *ldb_ch;
>> + int ret, i;
>> +
>> + imx8qxp_ldb = devm_kzalloc(dev, sizeof(*imx8qxp_ldb), GFP_KERNEL);
>> + if (!imx8qxp_ldb)
>> + return -ENOMEM;
>> +
>> + imx8qxp_ldb->clk_pixel = devm_clk_get(dev, "pixel");
>> + if (IS_ERR(imx8qxp_ldb->clk_pixel)) {
>> + ret = PTR_ERR(imx8qxp_ldb->clk_pixel);
>> + if (ret != -EPROBE_DEFER)
>> + DRM_DEV_ERROR(dev,
>> + "failed to get pixel clock: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + imx8qxp_ldb->clk_bypass = devm_clk_get(dev, "bypass");
>> + if (IS_ERR(imx8qxp_ldb->clk_bypass)) {
>> + ret = PTR_ERR(imx8qxp_ldb->clk_bypass);
>> + if (ret != -EPROBE_DEFER)
>> + DRM_DEV_ERROR(dev,
>> + "failed to get bypass clock: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + imx8qxp_ldb->dev = dev;
>> +
>> + ldb = &imx8qxp_ldb->base;
>> + ldb->dev = dev;
>> + ldb->ctrl_reg = 0xe0;
>> +
>> + for (i = 0; i < MAX_LDB_CHAN_NUM; i++)
>> + ldb->channel[i] = &imx8qxp_ldb->channel[i].base;
>> +
>> + ret = ldb_init_helper(ldb);
>> + if (ret)
>> + return ret;
>> +
>> + if (ldb->available_ch_cnt == 0) {
>> + DRM_DEV_DEBUG_DRIVER(dev, "no available channel\n");
>> + return 0;
>> + } else if (ldb->available_ch_cnt > 1) {
>> + DRM_DEV_ERROR(dev, "invalid available channel number(%u)\n",
>> + ldb->available_ch_cnt);
>> + return -ENOTSUPP;
>> + }
>> +
>> + for (i = 0; i < MAX_LDB_CHAN_NUM; i++) {
>> + imx8qxp_ldb_ch = &imx8qxp_ldb->channel[i];
>> + ldb_ch = &imx8qxp_ldb_ch->base;
>> +
>> + if (ldb_ch->is_available) {
>> + imx8qxp_ldb->active_chno = ldb_ch->chno;
>> + break;
>> + }
>> + }
>> +
>> + imx8qxp_ldb_ch->phy = devm_of_phy_get(dev, ldb_ch->np, "lvds_phy");
>> + if (IS_ERR(imx8qxp_ldb_ch->phy)) {
>> + ret = PTR_ERR(imx8qxp_ldb_ch->phy);
>> + if (ret != -EPROBE_DEFER)
>> + DRM_DEV_ERROR(dev, "failed to get channel%d PHY: %d\n",
>> + imx8qxp_ldb->active_chno, ret);
>> + return ret;
>> + }
>> +
>> + ret = ldb_find_next_bridge_helper(ldb);
>> + if (ret)
>> + return ret;
>> +
>> + ret = imx8qxp_ldb_set_di_id(imx8qxp_ldb);
>> + if (ret)
>> + return ret;
>> +
>> + ret = imx8qxp_ldb_parse_dt_companion(imx8qxp_ldb);
>> + if (ret)
>> + return ret;
>> +
>> + platform_set_drvdata(pdev, imx8qxp_ldb);
>> + pm_runtime_enable(dev);
>> +
>> + ldb_add_bridge_helper(ldb, &imx8qxp_ldb_bridge_funcs);
>> +
>> + return ret;
>> +}
>> +
>> +static int imx8qxp_ldb_remove(struct platform_device *pdev)
>> +{
>> + struct imx8qxp_ldb *imx8qxp_ldb = platform_get_drvdata(pdev);
>> + struct ldb *ldb = &imx8qxp_ldb->base;
>> +
>> + ldb_remove_bridge_helper(ldb);
>> +
>> + pm_runtime_disable(&pdev->dev);
>> +
>> + return 0;
>> +}
>> +
>> +static int __maybe_unused imx8qxp_ldb_runtime_suspend(struct device *dev)
>> +{
>> + return 0;
>> +}
>> +
>> +static int __maybe_unused imx8qxp_ldb_runtime_resume(struct device *dev)
>> +{
>> + struct imx8qxp_ldb *imx8qxp_ldb = dev_get_drvdata(dev);
>> + struct ldb *ldb = &imx8qxp_ldb->base;
>> +
>> + /* disable LDB by resetting the control register to POR default */
>> + regmap_write(ldb->regmap, ldb->ctrl_reg, 0);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct dev_pm_ops imx8qxp_ldb_pm_ops = {
>> + SET_RUNTIME_PM_OPS(imx8qxp_ldb_runtime_suspend,
>> + imx8qxp_ldb_runtime_resume, NULL)
>> +};
>> +
>> +static const struct of_device_id imx8qxp_ldb_dt_ids[] = {
>> + { .compatible = "fsl,imx8qxp-ldb" },
>> + { /* sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, imx8qxp_ldb_dt_ids);
>> +
>> +static struct platform_driver imx8qxp_ldb_driver = {
>> + .probe = imx8qxp_ldb_probe,
>> + .remove = imx8qxp_ldb_remove,
>> + .driver = {
>> + .pm = &imx8qxp_ldb_pm_ops,
>> + .name = DRIVER_NAME,
>> + .of_match_table = imx8qxp_ldb_dt_ids,
>> + },
>> +};
>> +module_platform_driver(imx8qxp_ldb_driver);
>> +
>> +MODULE_DESCRIPTION("i.MX8QXP LVDS Display Bridge(LDB)/Pixel Mapper bridge 
>> driver");
>> +MODULE_AUTHOR("Liu Ying ");
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_ALIAS("platform:" DRIVER_NAME);
>> --
>> 2.7.4
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> --
>>
>> End of dri-devel Digest, Vol 132, Issue 197
>> ***
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.freedesktop.org/archives/dri-devel/attachments/20210310/ed86dd05/attachment.htm>
>
> --
>
> Subject: Digest Footer
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
>
> End of dri-devel Digest, Vol 132, Issue 206
> ***___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dri-devel Digest, Vol 132, Issue 196

[chatzem]

Sent from ProtonMail mobile

 Original Message 
On Mar 10, 2021, 12:10, wrote:

> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dri-devel digest..."
>
> Today's Topics:
>
> 1. [PATCH v5 10/14] drm/bridge: imx: Add LDB driver helper
> support (Liu Ying)
> 2. [PATCH v5 11/14] dt-bindings: display: bridge: Add
> i.MX8qm/qxp LVDS display bridge binding (Liu Ying)
>
> --
>
> Message: 1
> Date: Wed, 10 Mar 2021 17:55:34 +0800
> From: Liu Ying 
> To: dri-devel@lists.freedesktop.org, devicet...@vger.kernel.org,
> linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org,
> linux-me...@vger.kernel.org
> Cc: airl...@linux.ie, dan...@ffwll.ch, robh...@kernel.org,
> shawn...@kernel.org, s.ha...@pengutronix.de, ker...@pengutronix.de,
> feste...@gmail.com, linux-...@nxp.com, mche...@kernel.org,
> a.ha...@samsung.com, narmstr...@baylibre.com,
> laurent.pinch...@ideasonboard.com, jo...@kwiboo.se,
> jernej.skra...@siol.net, kis...@ti.com, vk...@kernel.org,
> robert.f...@linaro.org, lee.jo...@linaro.org
> Subject: [PATCH v5 10/14] drm/bridge: imx: Add LDB driver helper
> support
> Message-ID: <1615370138-5673-11-git-send-email-victor@nxp.com>
> Content-Type: text/plain
>
> This patch adds a helper to support LDB drm bridge drivers for
> i.MX SoCs. Helper functions supported by this helper should
> implement common logics for all LDB modules embedded in i.MX SoCs.
>
> Signed-off-by: Liu Ying 
> ---
> v4->v5:
> * Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
> driver and i.MX8qm LDB bridge driver. (Robert)
> * Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
> (Robert)
> * s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/ for 'imx-ldb-helper.h'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * Call syscon_node_to_regmap() to get regmap instead of
> syscon_regmap_lookup_by_phandle().
>
> v1->v2:
> * No change.
>
> drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 232 
> drivers/gpu/drm/bridge/imx/imx-ldb-helper.h | 98 
> 2 files changed, 330 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c 
> b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> new file mode 100644
> index ..d01c4ff9
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> @@ -0,0 +1,232 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2012 Sascha Hauer, Pengutronix
> + * Copyright 2019,2020 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-ldb-helper.h"
> +
> +bool ldb_channel_is_single_link(struct ldb_channel *ldb_ch)
> +{
> + return ldb_ch->link_type == LDB_CH_SINGLE_LINK;
> +}
> +
> +bool ldb_channel_is_split_link(struct ldb_channel *ldb_ch)
> +{
> + return ldb_ch->link_type == LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS ||
> + ldb_ch->link_type == LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
> +}
> +
> +int ldb_bridge_atomic_check_helper(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> +
> + ldb_ch->in_bus_format = bridge_state->input_bus_cfg.format;
> + ldb_ch->out_bus_format = bridge_state->output_bus_cfg.format;
> +
> + return 0;
> +}
> +
> +void ldb_bridge_mode_set_helper(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> + struct ldb *ldb = ldb_ch->ldb;
> + bool is_split = ldb_channel_is_split_link(ldb_ch);
> +
> + if (is_split)
> + ldb->ldb_ctrl |= LDB_SPLIT_MODE_EN;
> +
> + switch (ldb_ch->out_bus_format) {
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + if (ldb_ch->chno == 0 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24;
> + if (ldb_ch->chno == 1 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + if (ldb_ch->chno == 0 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24 |
> + LDB_BIT_MAP_CH0_JEIDA;
> + if (ldb_ch->chno == 1 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24 |
> + LDB_BIT_MAP_CH1_JEIDA;
> + break;
> + }
> +}
> +
> +void ldb_bridge_enable_helper(struct drm_bridge *bridge)
> +

Re: dri-devel Digest, Vol 132, Issue 196

[chatzem]

Sent from ProtonMail mobile

 Original Message 
On Mar 10, 2021, 12:10, wrote:

> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dri-devel digest..."
>
> Today's Topics:
>
> 1. [PATCH v5 10/14] drm/bridge: imx: Add LDB driver helper
> support (Liu Ying)
> 2. [PATCH v5 11/14] dt-bindings: display: bridge: Add
> i.MX8qm/qxp LVDS display bridge binding (Liu Ying)
>
> --
>
> Message: 1
> Date: Wed, 10 Mar 2021 17:55:34 +0800
> From: Liu Ying 
> To: dri-devel@lists.freedesktop.org, devicet...@vger.kernel.org,
> linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org,
> linux-me...@vger.kernel.org
> Cc: airl...@linux.ie, dan...@ffwll.ch, robh...@kernel.org,
> shawn...@kernel.org, s.ha...@pengutronix.de, ker...@pengutronix.de,
> feste...@gmail.com, linux-...@nxp.com, mche...@kernel.org,
> a.ha...@samsung.com, narmstr...@baylibre.com,
> laurent.pinch...@ideasonboard.com, jo...@kwiboo.se,
> jernej.skra...@siol.net, kis...@ti.com, vk...@kernel.org,
> robert.f...@linaro.org, lee.jo...@linaro.org
> Subject: [PATCH v5 10/14] drm/bridge: imx: Add LDB driver helper
> support
> Message-ID: <1615370138-5673-11-git-send-email-victor@nxp.com>
> Content-Type: text/plain
>
> This patch adds a helper to support LDB drm bridge drivers for
> i.MX SoCs. Helper functions supported by this helper should
> implement common logics for all LDB modules embedded in i.MX SoCs.
>
> Signed-off-by: Liu Ying 
> ---
> v4->v5:
> * Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
> driver and i.MX8qm LDB bridge driver. (Robert)
> * Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
> (Robert)
> * s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/ for 'imx-ldb-helper.h'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * Call syscon_node_to_regmap() to get regmap instead of
> syscon_regmap_lookup_by_phandle().
>
> v1->v2:
> * No change.
>
> drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 232 
> drivers/gpu/drm/bridge/imx/imx-ldb-helper.h | 98 
> 2 files changed, 330 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c 
> b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> new file mode 100644
> index ..d01c4ff9
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> @@ -0,0 +1,232 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2012 Sascha Hauer, Pengutronix
> + * Copyright 2019,2020 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-ldb-helper.h"
> +
> +bool ldb_channel_is_single_link(struct ldb_channel *ldb_ch)
> +{
> + return ldb_ch->link_type == LDB_CH_SINGLE_LINK;
> +}
> +
> +bool ldb_channel_is_split_link(struct ldb_channel *ldb_ch)
> +{
> + return ldb_ch->link_type == LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS ||
> + ldb_ch->link_type == LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
> +}
> +
> +int ldb_bridge_atomic_check_helper(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> +
> + ldb_ch->in_bus_format = bridge_state->input_bus_cfg.format;
> + ldb_ch->out_bus_format = bridge_state->output_bus_cfg.format;
> +
> + return 0;
> +}
> +
> +void ldb_bridge_mode_set_helper(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> + struct ldb *ldb = ldb_ch->ldb;
> + bool is_split = ldb_channel_is_split_link(ldb_ch);
> +
> + if (is_split)
> + ldb->ldb_ctrl |= LDB_SPLIT_MODE_EN;
> +
> + switch (ldb_ch->out_bus_format) {
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + if (ldb_ch->chno == 0 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24;
> + if (ldb_ch->chno == 1 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + if (ldb_ch->chno == 0 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24 |
> + LDB_BIT_MAP_CH0_JEIDA;
> + if (ldb_ch->chno == 1 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24 |
> + LDB_BIT_MAP_CH1_JEIDA;
> + break;
> + }
> +}
> +
> +void ldb_bridge_enable_helper(struct drm_bridge *bridge)
> +

Re: dri-devel Digest, Vol 132, Issue 198

[chatzem]

Sent from ProtonMail mobile

 Original Message 
On Mar 10, 2021, 12:10, wrote:

> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dri-devel digest..."
>
> Today's Topics:
>
> 1. [PATCH v5 13/14] drm/bridge: imx: Add LDB support for i.MX8qm
> (Liu Ying)
> 2. [PATCH v5 14/14] MAINTAINERS: add maintainer for DRM bridge
> drivers for i.MX SoCs (Liu Ying)
>
> --
>
> Message: 1
> Date: Wed, 10 Mar 2021 17:55:37 +0800
> From: Liu Ying 
> To: dri-devel@lists.freedesktop.org, devicet...@vger.kernel.org,
> linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org,
> linux-me...@vger.kernel.org
> Cc: airl...@linux.ie, dan...@ffwll.ch, robh...@kernel.org,
> shawn...@kernel.org, s.ha...@pengutronix.de, ker...@pengutronix.de,
> feste...@gmail.com, linux-...@nxp.com, mche...@kernel.org,
> a.ha...@samsung.com, narmstr...@baylibre.com,
> laurent.pinch...@ideasonboard.com, jo...@kwiboo.se,
> jernej.skra...@siol.net, kis...@ti.com, vk...@kernel.org,
> robert.f...@linaro.org, lee.jo...@linaro.org
> Subject: [PATCH v5 13/14] drm/bridge: imx: Add LDB support for i.MX8qm
> Message-ID: <1615370138-5673-14-git-send-email-victor@nxp.com>
> Content-Type: text/plain
>
> This patch adds a drm bridge driver for i.MX8qm LVDS display bridge(LDB)
> which is officially named as pixel mapper. The LDB has two channels.
> Each of them supports up to 30bpp parallel input color format and can
> map the input to VESA or JEIDA standards. The two channels can be used
> simultaneously, either in dual mode or split mode. In dual mode, the
> two channels output identical data. In split mode, channel0 outputs
> odd pixels and channel1 outputs even pixels. This patch supports the
> LDB single mode and split mode.
>
> Signed-off-by: Liu Ying 
> ---
> Note that this patch depends on the patch 'phy: Add LVDS configuration 
> options',
> which has already been sent with the following series to add Mixel combo PHY
> found in i.MX8qxp:
> https://www.spinics.net/lists/arm-kernel/msg879957.html
>
> v4->v5:
> * Link with the imx-ldb-helper object. (Robert)
> * Correspondingly, rename 'imx8qm-ldb.c' to 'imx8qm-ldb-drv.c'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * No change.
>
> v1->v2:
> * Drop unnecessary check for maximum available LDB channels.
> * Mention i.MX8qm LDB official name 'pixel mapper' in the bridge driver
> and Kconfig help message.
>
> drivers/gpu/drm/bridge/imx/Kconfig | 9 +
> drivers/gpu/drm/bridge/imx/Makefile | 3 +
> drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c | 586 
> 3 files changed, 598 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
>
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig 
> b/drivers/gpu/drm/bridge/imx/Kconfig
> index 94f8db4d..3a8683f 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -1,3 +1,12 @@
> +config DRM_IMX8QM_LDB
> + tristate "Freescale i.MX8QM LVDS display bridge"
> + depends on OF
> + depends on COMMON_CLK
> + select DRM_KMS_HELPER
> + help
> + Choose this to enable the internal LVDS Display Bridge(LDB) found in
> + Freescale i.MX8qm processor. Official name of LDB is pixel mapper.
> +
> config DRM_IMX8QXP_LDB
> tristate "Freescale i.MX8QXP LVDS display bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile 
> b/drivers/gpu/drm/bridge/imx/Makefile
> index 96d5d1e..aa90ec8 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,3 +1,6 @@
> +imx8qm-ldb-objs := imx-ldb-helper.o imx8qm-ldb-drv.o
> +obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
> +
> imx8qxp-ldb-objs := imx-ldb-helper.o imx8qxp-ldb-drv.o
> obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c 
> b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> new file mode 100644
> index ..6c92636
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb-drv.c
> @@ -0,0 +1,586 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright 2020 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-ldb-helper.h"
> +
> +#define LDB_CH0_10BIT_EN (1 << 22)
> +#define LDB_CH1_10BIT_EN (1 << 23)
> +#define LDB_CH0_DATA_WIDTH_24BIT (1 << 24)
> +#define LDB_CH1_DATA_WIDTH_24BIT (1 << 26)
> +#define LDB_CH0_DATA_WIDTH_30BIT (2 << 24

Re: dri-devel Digest, Vol 132, Issue 196

[chatzem]

Sent from ProtonMail mobile

 Original Message 
On Mar 10, 2021, 12:10, wrote:

> Send dri-devel mailing list submissions to
> dri-devel@lists.freedesktop.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> or, via email, send a message with subject or body 'help' to
> dri-devel-requ...@lists.freedesktop.org
>
> You can reach the person managing the list at
> dri-devel-ow...@lists.freedesktop.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dri-devel digest..."
>
> Today's Topics:
>
> 1. [PATCH v5 10/14] drm/bridge: imx: Add LDB driver helper
> support (Liu Ying)
> 2. [PATCH v5 11/14] dt-bindings: display: bridge: Add
> i.MX8qm/qxp LVDS display bridge binding (Liu Ying)
>
> --
>
> Message: 1
> Date: Wed, 10 Mar 2021 17:55:34 +0800
> From: Liu Ying 
> To: dri-devel@lists.freedesktop.org, devicet...@vger.kernel.org,
> linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org,
> linux-me...@vger.kernel.org
> Cc: airl...@linux.ie, dan...@ffwll.ch, robh...@kernel.org,
> shawn...@kernel.org, s.ha...@pengutronix.de, ker...@pengutronix.de,
> feste...@gmail.com, linux-...@nxp.com, mche...@kernel.org,
> a.ha...@samsung.com, narmstr...@baylibre.com,
> laurent.pinch...@ideasonboard.com, jo...@kwiboo.se,
> jernej.skra...@siol.net, kis...@ti.com, vk...@kernel.org,
> robert.f...@linaro.org, lee.jo...@linaro.org
> Subject: [PATCH v5 10/14] drm/bridge: imx: Add LDB driver helper
> support
> Message-ID: <1615370138-5673-11-git-send-email-victor@nxp.com>
> Content-Type: text/plain
>
> This patch adds a helper to support LDB drm bridge drivers for
> i.MX SoCs. Helper functions supported by this helper should
> implement common logics for all LDB modules embedded in i.MX SoCs.
>
> Signed-off-by: Liu Ying 
> ---
> v4->v5:
> * Make imx-ldb-helper be a pure object to be linked with i.MX8qxp LDB bridge
> driver and i.MX8qm LDB bridge driver. (Robert)
> * Move 'imx_ldb_helper.h' to 'drivers/gpu/drm/bridge/imx/imx-ldb-helper.h'.
> (Robert)
> * s/__FSL_IMX_LDB__/__IMX_LDB_HELPER__/ for 'imx-ldb-helper.h'.
>
> v3->v4:
> * No change.
>
> v2->v3:
> * Call syscon_node_to_regmap() to get regmap instead of
> syscon_regmap_lookup_by_phandle().
>
> v1->v2:
> * No change.
>
> drivers/gpu/drm/bridge/imx/imx-ldb-helper.c | 232 
> drivers/gpu/drm/bridge/imx/imx-ldb-helper.h | 98 
> 2 files changed, 330 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> create mode 100644 drivers/gpu/drm/bridge/imx/imx-ldb-helper.h
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c 
> b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> new file mode 100644
> index ..d01c4ff9
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx-ldb-helper.c
> @@ -0,0 +1,232 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2012 Sascha Hauer, Pengutronix
> + * Copyright 2019,2020 NXP
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "imx-ldb-helper.h"
> +
> +bool ldb_channel_is_single_link(struct ldb_channel *ldb_ch)
> +{
> + return ldb_ch->link_type == LDB_CH_SINGLE_LINK;
> +}
> +
> +bool ldb_channel_is_split_link(struct ldb_channel *ldb_ch)
> +{
> + return ldb_ch->link_type == LDB_CH_DUAL_LINK_EVEN_ODD_PIXELS ||
> + ldb_ch->link_type == LDB_CH_DUAL_LINK_ODD_EVEN_PIXELS;
> +}
> +
> +int ldb_bridge_atomic_check_helper(struct drm_bridge *bridge,
> + struct drm_bridge_state *bridge_state,
> + struct drm_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> +
> + ldb_ch->in_bus_format = bridge_state->input_bus_cfg.format;
> + ldb_ch->out_bus_format = bridge_state->output_bus_cfg.format;
> +
> + return 0;
> +}
> +
> +void ldb_bridge_mode_set_helper(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode,
> + const struct drm_display_mode *adjusted_mode)
> +{
> + struct ldb_channel *ldb_ch = bridge->driver_private;
> + struct ldb *ldb = ldb_ch->ldb;
> + bool is_split = ldb_channel_is_split_link(ldb_ch);
> +
> + if (is_split)
> + ldb->ldb_ctrl |= LDB_SPLIT_MODE_EN;
> +
> + switch (ldb_ch->out_bus_format) {
> + case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG:
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_SPWG:
> + if (ldb_ch->chno == 0 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24;
> + if (ldb_ch->chno == 1 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24;
> + break;
> + case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA:
> + if (ldb_ch->chno == 0 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH0_24 |
> + LDB_BIT_MAP_CH0_JEIDA;
> + if (ldb_ch->chno == 1 || is_split)
> + ldb->ldb_ctrl |= LDB_DATA_WIDTH_CH1_24 |
> + LDB_BIT_MAP_CH1_JEIDA;
> + break;
> + }
> +}
> +
> +void ldb_bridge_enable_helper(struct drm_bridge *bridge)
> +

Re: [PATCH 14/17] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE

[Robin Murphy]

On 2021-03-10 09:25, Christoph Hellwig wrote:

On Wed, Mar 10, 2021 at 10:15:01AM +0100, Christoph Hellwig wrote:

On Thu, Mar 04, 2021 at 03:25:27PM +, Robin Murphy wrote:

On 2021-03-01 08:42, Christoph Hellwig wrote:

Use explicit methods for setting and querying the information instead.


Now that everyone's using iommu-dma, is there any point in bouncing this
through the drivers at all? Seems like it would make more sense for the x86
drivers to reflect their private options back to iommu_dma_strict (and
allow Intel's caching mode to override it as well), then have
iommu_dma_init_domain just test !iommu_dma_strict &&
domain->ops->flush_iotlb_all.


Hmm.  I looked at this, and kill off ->dma_enable_flush_queue for
the ARM drivers and just looking at iommu_dma_strict seems like a
very clear win.

OTOH x86 is a little more complicated.  AMD and intel defaul to lazy
mode, so we'd have to change the global iommu_dma_strict if they are
initialized.  Also Intel has not only a "static" option to disable
lazy mode, but also a "dynamic" one where it iterates structure.  So
I think on the get side we're stuck with the method, but it still
simplifies the whole thing.


Actually... Just mirroring the iommu_dma_strict value into
struct iommu_domain should solve all of that with very little
boilerplate code.


Yes, my initial thought was to directly replace the attribute with a
common flag at iommu_domain level, but since in all cases the behaviour
is effectively global rather than actually per-domain, it seemed
reasonable to take it a step further. This passes compile-testing for
arm64 and x86, what do you think?

Robin.

->8-
Subject: [PATCH] iommu: Consolidate strict invalidation handling

Now that everyone is using iommu-dma, the global invalidation policy
really doesn't need to be woven through several parts of the core API
and individual drivers, we can just look it up directly at the one point
that we now make the flush queue decision. If the x86 drivers reflect
their internal options and overrides back to iommu_dma_strict, that can
become the canonical source.

Signed-off-by: Robin Murphy 
---
 drivers/iommu/amd/iommu.c   |  2 ++
 drivers/iommu/dma-iommu.c   |  8 +---
 drivers/iommu/intel/iommu.c | 12 
 drivers/iommu/iommu.c   | 35 +++
 include/linux/iommu.h   |  2 ++
 5 files changed, 44 insertions(+), 15 deletions(-)

diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c
index a69a8b573e40..1db29e59d468 100644
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -1856,6 +1856,8 @@ int __init amd_iommu_init_dma_ops(void)
else
pr_info("Lazy IO/TLB flushing enabled\n");
 
+	iommu_set_dma_strict(amd_iommu_unmap_flush);

+
return 0;
 
 }

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index af765c813cc8..789a950cc125 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -304,10 +304,6 @@ static void iommu_dma_flush_iotlb_all(struct iova_domain 
*iovad)
 
 	cookie = container_of(iovad, struct iommu_dma_cookie, iovad);

domain = cookie->fq_domain;
-   /*
-* The IOMMU driver supporting DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
-* implies that ops->flush_iotlb_all must be non-NULL.
-*/
domain->ops->flush_iotlb_all(domain);
 }
 
@@ -334,7 +330,6 @@ static int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,

struct iommu_dma_cookie *cookie = domain->iova_cookie;
unsigned long order, base_pfn;
struct iova_domain *iovad;
-   int attr;
 
 	if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)

return -EINVAL;
@@ -371,8 +366,7 @@ static int iommu_dma_init_domain(struct iommu_domain 
*domain, dma_addr_t base,
init_iova_domain(iovad, 1UL << order, base_pfn);
 
 	if (!cookie->fq_domain && (!dev || !dev_is_untrusted(dev)) &&

-   !iommu_domain_get_attr(domain, DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE, &attr) 
&&
-   attr) {
+   domain->ops->flush_iotlb_all && !iommu_get_dma_strict()) {
if (init_iova_flush_queue(iovad, iommu_dma_flush_iotlb_all,
  iommu_dma_entry_dtor))
pr_warn("iova flush queue initialization failed\n");
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index b5c746f0f63b..f5b452cd1266 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -4377,6 +4377,17 @@ int __init intel_iommu_init(void)
 
 	down_read(&dmar_global_lock);

for_each_active_iommu(iommu, drhd) {
+   if (!intel_iommu_strict && cap_caching_mode(iommu->cap)) {
+   /*
+* The flush queue implementation does not perform 
page-selective
+* invalidations that are required for efficient TLB 
flushes in
+* virtual environments. The bene

Re: [PATCH] fb_defio: Remove custom address_space_operations

[Matthew Wilcox]

On Wed, Mar 10, 2021 at 06:38:07PM +, William Kucharski wrote:
> Looks good, just one super minor nit inline.
> > @@ -228,13 +202,6 @@ void fb_deferred_io_cleanup(struct fb_info *info)
> > 
> > BUG_ON(!fbdefio);
> > cancel_delayed_work_sync(&info->deferred_work);
> > -
> > -   /* clear out the mapping that we setup */
> > -   for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
> > -   page = fb_deferred_io_page(info, i);
> > -   page->mapping = NULL;
> > -   }
> > -
> > mutex_destroy(&fbdefio->lock);
> > }
> 
> We no longer need the definition of "int i" right before the BUG_ON().

Huh.  Usually gcc warns about that.  let me figure that out and post a v2.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] drm/dp_helper: Define options for FRL training for HDMI2.1 PCON

[Ville Syrjälä]

On Tue, Mar 09, 2021 at 10:09:13AM +0530, Ankit Nautiyal wrote:
> Currently the FRL training mode (Concurrent, Sequential) and
> training type (Normal, Extended) are not defined properly and
> are passed as bool values in drm_helpers for pcon
> configuration for FRL training.
> 
> This patch:
> -Add register masks for Sequential and Normal FRL training options.
> -Fixes the drm_helpers for FRL Training configuration to use the
>  appropriate masks.
> -Modifies the calls to the above drm_helpers in i915/intel_dp as per
>  the above change.
> 
> v2: Re-used the register masks for these options, instead of enum. (Ville)
> 
> Signed-off-by: Ankit Nautiyal 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 24 ++--
>  drivers/gpu/drm/i915/display/intel_dp.c | 10 --
>  include/drm/drm_dp_helper.h |  6 --
>  3 files changed, 22 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index eedbb48815b7..cb2f53e56685 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -2635,14 +2635,16 @@ EXPORT_SYMBOL(drm_dp_pcon_is_frl_ready);
>   * drm_dp_pcon_frl_configure_1() - Set HDMI LINK Configuration-Step1
>   * @aux: DisplayPort AUX channel
>   * @max_frl_gbps: maximum frl bw to be configured between PCON and HDMI sink
> - * @concurrent_mode: true if concurrent mode or operation is required,
> - * false otherwise.
> + * @frl_mode: FRL Training mode, it can be either Concurrent or Sequential.
> + * In Concurrent Mode, the FRL link bring up can be done along with
> + * DP Link training. In Sequential mode, the FRL link bring up is done prior 
> to
> + * the DP Link training.
>   *
>   * Returns 0 if success, else returns negative error code.
>   */
>  
>  int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, int max_frl_gbps,
> - bool concurrent_mode)
> + u8 frl_mode)
>  {
>   int ret;
>   u8 buf;
> @@ -2651,7 +2653,7 @@ int drm_dp_pcon_frl_configure_1(struct drm_dp_aux *aux, 
> int max_frl_gbps,
>   if (ret < 0)
>   return ret;
>  
> - if (concurrent_mode)
> + if (frl_mode == DP_PCON_ENABLE_CONCURRENT_LINK)
>   buf |= DP_PCON_ENABLE_CONCURRENT_LINK;
>   else
>   buf &= ~DP_PCON_ENABLE_CONCURRENT_LINK;
> @@ -2694,21 +2696,23 @@ EXPORT_SYMBOL(drm_dp_pcon_frl_configure_1);
>   * drm_dp_pcon_frl_configure_2() - Set HDMI Link configuration Step-2
>   * @aux: DisplayPort AUX channel
>   * @max_frl_mask : Max FRL BW to be tried by the PCON with HDMI Sink
> - * @extended_train_mode : true for Extended Mode, false for Normal Mode.
> - * In Normal mode, the PCON tries each frl bw from the max_frl_mask starting
> - * from min, and stops when link training is successful. In Extended mode, 
> all
> - * frl bw selected in the mask are trained by the PCON.
> + * @frl_type : FRL training type, can be Extended, or Normal.
> + * In Normal FRL training, the PCON tries each frl bw from the max_frl_mask
> + * starting from min, and stops when link training is successful. In Extended
> + * FRL training, all frl bw selected in the mask are trained by the PCON.
>   *
>   * Returns 0 if success, else returns negative error code.
>   */
>  int drm_dp_pcon_frl_configure_2(struct drm_dp_aux *aux, int max_frl_mask,
> - bool extended_train_mode)
> + u8 frl_type)
>  {
>   int ret;
>   u8 buf = max_frl_mask;
>  
> - if (extended_train_mode)
> + if (frl_type == DP_PCON_FRL_LINK_TRAIN_EXTENDED)
>   buf |= DP_PCON_FRL_LINK_TRAIN_EXTENDED;
> + else
> + buf &= ~DP_PCON_FRL_LINK_TRAIN_EXTENDED;
>  
>   ret = drm_dp_dpcd_writeb(aux, DP_PCON_HDMI_LINK_CONFIG_2, buf);
>   if (ret < 0)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 4f89e0de5dde..85ec74ae952e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2557,10 +2557,6 @@ static int intel_dp_hdmi_sink_max_frl(struct intel_dp 
> *intel_dp)
>  
>  static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
>  {
> -#define PCON_EXTENDED_TRAIN_MODE (1 > 0)
> -#define PCON_CONCURRENT_MODE (1 > 0)
> -#define PCON_SEQUENTIAL_MODE !PCON_CONCURRENT_MODE
> -#define PCON_NORMAL_TRAIN_MODE !PCON_EXTENDED_TRAIN_MODE
>  #define TIMEOUT_FRL_READY_MS 500
>  #define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
>  
> @@ -2594,10 +2590,12 @@ static int intel_dp_pcon_start_frl_training(struct 
> intel_dp *intel_dp)
>   return -ETIMEDOUT;
>  
>   max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
> - ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw, 
> PCON_SEQUENTIAL_MODE);
> + ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
> +   

Re: [Intel-gfx] [RFC v1 1/6] drm/edid: make a number of functions, parameters and variables const

[Ville Syrjälä]

On Tue, Mar 09, 2021 at 03:54:09PM +0200, Jani Nikula wrote:
> If there's no need to change it, it should be const. There's more to be
> done, but start off with changes that make follow-up work easier. No
> functional changes.
> 
> Signed-off-by: Jani Nikula 

const is good.

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid.c  | 58 ++---
>  include/drm/drm_displayid.h |  4 +--
>  2 files changed, 31 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c2bbe7bee7b6..d510b827a1f8 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1585,7 +1585,7 @@ module_param_named(edid_fixup, edid_fixup, int, 0400);
>  MODULE_PARM_DESC(edid_fixup,
>"Minimum number of valid EDID header bytes (0-8, default 6)");
>  
> -static int validate_displayid(u8 *displayid, int length, int idx);
> +static int validate_displayid(const u8 *displayid, int length, int idx);
>  
>  static int drm_edid_block_checksum(const u8 *raw_edid)
>  {
> @@ -3241,10 +3241,10 @@ add_detailed_modes(struct drm_connector *connector, 
> struct edid *edid,
>  /*
>   * Search EDID for CEA extension block.
>   */
> -static u8 *drm_find_edid_extension(const struct edid *edid,
> -int ext_id, int *ext_index)
> +static const u8 *drm_find_edid_extension(const struct edid *edid,
> +  int ext_id, int *ext_index)
>  {
> - u8 *edid_ext = NULL;
> + const u8 *edid_ext = NULL;
>   int i;
>  
>   /* No EDID or EDID extensions */
> @@ -3253,7 +3253,7 @@ static u8 *drm_find_edid_extension(const struct edid 
> *edid,
>  
>   /* Find CEA extension */
>   for (i = *ext_index; i < edid->extensions; i++) {
> - edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
> + edid_ext = (const u8 *)edid + EDID_LENGTH * (i + 1);
>   if (edid_ext[0] == ext_id)
>   break;
>   }
> @@ -3267,12 +3267,12 @@ static u8 *drm_find_edid_extension(const struct edid 
> *edid,
>  }
>  
>  
> -static u8 *drm_find_displayid_extension(const struct edid *edid,
> - int *length, int *idx,
> - int *ext_index)
> +static const u8 *drm_find_displayid_extension(const struct edid *edid,
> +   int *length, int *idx,
> +   int *ext_index)
>  {
> - u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
> - struct displayid_hdr *base;
> + const u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, 
> ext_index);
> + const struct displayid_hdr *base;
>   int ret;
>  
>   if (!displayid)
> @@ -3286,18 +3286,18 @@ static u8 *drm_find_displayid_extension(const struct 
> edid *edid,
>   if (ret)
>   return NULL;
>  
> - base = (struct displayid_hdr *)&displayid[*idx];
> + base = (const struct displayid_hdr *)&displayid[*idx];
>   *length = *idx + sizeof(*base) + base->bytes;
>  
>   return displayid;
>  }
>  
> -static u8 *drm_find_cea_extension(const struct edid *edid)
> +static const u8 *drm_find_cea_extension(const struct edid *edid)
>  {
>   int length, idx;
> - struct displayid_block *block;
> - u8 *cea;
> - u8 *displayid;
> + const struct displayid_block *block;
> + const u8 *cea;
> + const u8 *displayid;
>   int ext_index;
>  
>   /* Look for a top level CEA extension block */
> @@ -3318,7 +3318,7 @@ static u8 *drm_find_cea_extension(const struct edid 
> *edid)
>   idx += sizeof(struct displayid_hdr);
>   for_each_displayid_db(displayid, block, idx, length) {
>   if (block->tag == DATA_BLOCK_CTA)
> - return (u8 *)block;
> + return (const u8 *)block;
>   }
>   }
>  
> @@ -4503,8 +4503,8 @@ static void clear_eld(struct drm_connector *connector)
>  static void drm_edid_to_eld(struct drm_connector *connector, struct edid 
> *edid)
>  {
>   uint8_t *eld = connector->eld;
> - u8 *cea;
> - u8 *db;
> + const u8 *cea;
> + const u8 *db;
>   int total_sad_count = 0;
>   int mnl;
>   int dbl;
> @@ -4600,7 +4600,7 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad 
> **sads)
>  {
>   int count = 0;
>   int i, start, end, dbl;
> - u8 *cea;
> + const u8 *cea;
>  
>   cea = drm_find_cea_extension(edid);
>   if (!cea) {
> @@ -4619,7 +4619,7 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad 
> **sads)
>   }
>  
>   for_each_cea_db(cea, i, start, end) {
> - u8 *db = &cea[i];
> + const u8 *db = &cea[i];
>  
>   if (cea_db_tag(db) == AUDIO_BLOCK) {
>   int j;
> @@ -4631,7 +4631,7 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad

[PATCH v2] fb_defio: Remove custom address_space_operations

[Matthew Wilcox (Oracle)]

There's no need to give the page an address_space.  Leaving the
page->mapping as NULL will cause the VM to handle set_page_dirty()
the same way that it's handled now, and that was the only reason to
set the address_space in the first place.

Signed-off-by: Matthew Wilcox (Oracle) 
Reviewed-by: Christoph Hellwig 
Reviewed-by: William Kucharski 
---
v2: Delete local variable definitions
 drivers/video/fbdev/core/fb_defio.c | 35 -
 drivers/video/fbdev/core/fbmem.c|  4 
 include/linux/fb.h  |  3 ---
 3 files changed, 42 deletions(-)

diff --git a/drivers/video/fbdev/core/fb_defio.c 
b/drivers/video/fbdev/core/fb_defio.c
index a591d291b231..b292887a2481 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -52,13 +52,6 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault *vmf)
return VM_FAULT_SIGBUS;
 
get_page(page);
-
-   if (vmf->vma->vm_file)
-   page->mapping = vmf->vma->vm_file->f_mapping;
-   else
-   printk(KERN_ERR "no mapping available\n");
-
-   BUG_ON(!page->mapping);
page->index = vmf->pgoff;
 
vmf->page = page;
@@ -151,17 +144,6 @@ static const struct vm_operations_struct 
fb_deferred_io_vm_ops = {
.page_mkwrite   = fb_deferred_io_mkwrite,
 };
 
-static int fb_deferred_io_set_page_dirty(struct page *page)
-{
-   if (!PageDirty(page))
-   SetPageDirty(page);
-   return 0;
-}
-
-static const struct address_space_operations fb_deferred_io_aops = {
-   .set_page_dirty = fb_deferred_io_set_page_dirty,
-};
-
 int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
 {
vma->vm_ops = &fb_deferred_io_vm_ops;
@@ -212,29 +194,12 @@ void fb_deferred_io_init(struct fb_info *info)
 }
 EXPORT_SYMBOL_GPL(fb_deferred_io_init);
 
-void fb_deferred_io_open(struct fb_info *info,
-struct inode *inode,
-struct file *file)
-{
-   file->f_mapping->a_ops = &fb_deferred_io_aops;
-}
-EXPORT_SYMBOL_GPL(fb_deferred_io_open);
-
 void fb_deferred_io_cleanup(struct fb_info *info)
 {
struct fb_deferred_io *fbdefio = info->fbdefio;
-   struct page *page;
-   int i;
 
BUG_ON(!fbdefio);
cancel_delayed_work_sync(&info->deferred_work);
-
-   /* clear out the mapping that we setup */
-   for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
-   page = fb_deferred_io_page(info, i);
-   page->mapping = NULL;
-   }
-
mutex_destroy(&fbdefio->lock);
 }
 EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 06f5805de2de..372b52a2befa 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1415,10 +1415,6 @@ __releases(&info->lock)
if (res)
module_put(info->fbops->owner);
}
-#ifdef CONFIG_FB_DEFERRED_IO
-   if (info->fbdefio)
-   fb_deferred_io_open(info, inode, file);
-#endif
 out:
unlock_fb_info(info);
if (res)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index ecfbcc0553a5..a8dccd23c249 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -659,9 +659,6 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
d_pitch,
 /* drivers/video/fb_defio.c */
 int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
 extern void fb_deferred_io_init(struct fb_info *info);
-extern void fb_deferred_io_open(struct fb_info *info,
-   struct inode *inode,
-   struct file *file);
 extern void fb_deferred_io_cleanup(struct fb_info *info);
 extern int fb_deferred_io_fsync(struct file *file, loff_t start,
loff_t end, int datasync);
-- 
2.30.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC v1 2/6] drm/displayid: add separate drm_displayid.c

[Ville Syrjälä]

On Tue, Mar 09, 2021 at 03:54:10PM +0200, Jani Nikula wrote:
> We'll be adding more DisplayID specific functions going forward, so
> start off by splitting out a few functions to a separate file.
> 
> We don't bother with exporting the functions; at least for now they
> should be needed solely within drm.ko.
> 
> No functional changes.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/Makefile|  2 +-
>  drivers/gpu/drm/drm_displayid.c | 59 +
>  drivers/gpu/drm/drm_edid.c  | 58 ++--
>  include/drm/drm_displayid.h |  8 +
>  include/drm/drm_edid.h  |  3 ++
>  5 files changed, 73 insertions(+), 57 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_displayid.c
> 
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 5eb5bf7c16e3..78ef2fd14f10 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -7,7 +7,7 @@ drm-y   :=drm_auth.o drm_cache.o \
>   drm_file.o drm_gem.o drm_ioctl.o drm_irq.o \
>   drm_drv.o \
>   drm_sysfs.o drm_hashtab.o drm_mm.o \
> - drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
> + drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o drm_displayid.o \
>   drm_encoder_slave.o \
>   drm_trace_points.o drm_prime.o \
>   drm_rect.o drm_vma_manager.o drm_flip_work.o \
> diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
> new file mode 100644
> index ..908bbe6feb61
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_displayid.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +static int validate_displayid(const u8 *displayid, int length, int idx)
> +{
> + int i, dispid_length;
> + u8 csum = 0;
> + const struct displayid_hdr *base;
> +
> + base = (const struct displayid_hdr *)&displayid[idx];
> +
> + DRM_DEBUG_KMS("base revision 0x%x, length %d, %d %d\n",
> +   base->rev, base->bytes, base->prod_id, base->ext_count);
> +
> + /* +1 for DispID checksum */
> + dispid_length = sizeof(*base) + base->bytes + 1;
> + if (dispid_length > length - idx)
> + return -EINVAL;
> +
> + for (i = 0; i < dispid_length; i++)
> + csum += displayid[idx + i];
> + if (csum) {
> + DRM_NOTE("DisplayID checksum invalid, remainder is %d\n", csum);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +const u8 *drm_find_displayid_extension(const struct edid *edid,
> +int *length, int *idx,
> +int *ext_index)
> +{
> + const u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, 
> ext_index);
> + const struct displayid_hdr *base;
> + int ret;
> +
> + if (!displayid)
> + return NULL;
> +
> + /* EDID extensions block checksum isn't for us */
> + *length = EDID_LENGTH - 1;
> + *idx = 1;
> +
> + ret = validate_displayid(displayid, *length, *idx);
> + if (ret)
> + return NULL;
> +
> + base = (const struct displayid_hdr *)&displayid[*idx];
> + *length = *idx + sizeof(*base) + base->bytes;
> +
> + return displayid;
> +}
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index d510b827a1f8..58e61f792bc7 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1585,8 +1585,6 @@ module_param_named(edid_fixup, edid_fixup, int, 0400);
>  MODULE_PARM_DESC(edid_fixup,
>"Minimum number of valid EDID header bytes (0-8, default 6)");
>  
> -static int validate_displayid(const u8 *displayid, int length, int idx);
> -
>  static int drm_edid_block_checksum(const u8 *raw_edid)
>  {
>   int i;
> @@ -3241,8 +3239,8 @@ add_detailed_modes(struct drm_connector *connector, 
> struct edid *edid,
>  /*
>   * Search EDID for CEA extension block.
>   */
> -static const u8 *drm_find_edid_extension(const struct edid *edid,
> -  int ext_id, int *ext_index)
> +const u8 *drm_find_edid_extension(const struct edid *edid,
> +   int ext_id, int *ext_index)
>  {
>   const u8 *edid_ext = NULL;
>   int i;
> @@ -3266,32 +3264,6 @@ static const u8 *drm_find_edid_extension(const struct 
> edid *edid,
>   return edid_ext;
>  }
>  
> -
> -static const u8 *drm_find_displayid_extension(const struct edid *edid,
> -   int *length, int *idx,
> -   int *ext_index)
> -{
> - const u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, 
> ext_index);
> - const struct displayid_hdr *base;
> - int ret;
> -
> - if (!displayid)
> - return NULL;
> -
> - /* EDID

Re: [PATCH v2 5/5] drm/ingenic: Add option to alloc cached GEM buffers

[Paul Cercueil]

Hi Hillf,

Le lun. 8 mars 2021 à 11:47, Hillf Danton  a écrit :

On Sun,  7 Mar 2021 20:28:35 +  Paul Cercueil wrote:
 With the module parameter ingenic-drm.cached_gem_buffers, it is 
possible

 to specify that we want GEM buffers backed by non-coherent memory.

 This dramatically speeds up software rendering on Ingenic SoCs, 
even for
 tasks where write-combine memory should in theory be faster (e.g. 
simple

 blits).


Wondering if it is due to the tricks at [1].

If so, is dma_alloc_noncoherent() necessary in this patchset?


You confuse non-contiguous with non-coherent, which are two different 
things.


Cheers,
-Paul

Christoph can you give us a concise lesson on noncoherency covering 
at least

noncoherent device, noncoherent memory(used in this work), no coherent
caching(in [1]), their links to speedup, and the thumb rule to handle
noncoherency in workdays. It feels toe curling every time I see 
noncoherence

going downtown with speedup hand in hand.

[1] Subject: [PATCH 6/6] media: uvcvideo: Use dma_alloc_noncontiguos 
API

https://lore.kernel.org/lkml/20210301085236.947011-7-...@lst.de/#t



 Leave it disabled by default, since it is specific to one use-case
 (software rendering).

 v2: Rework code to work with new DRM APIs regarding plane states

 Signed-off-by: Paul Cercueil 
 ---
  drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 49 
++-

  drivers/gpu/drm/ingenic/ingenic-drm.h |  4 ++
  drivers/gpu/drm/ingenic/ingenic-ipu.c | 14 ++-
  3 files changed, 63 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c

 index d60e1eefc9d1..ba1ac0fcda74 100644
 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
 +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
 @@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -23,6 +24,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -99,6 +101,11 @@ struct ingenic_drm {
struct notifier_block clock_nb;
  };

 +static bool ingenic_drm_cached_gem_buf;
 +module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, 
bool, 0400);

 +MODULE_PARM_DESC(cached_gem_buffers,
 +   "Enable fully cached GEM buffers [default=false]");
 +
  static bool ingenic_drm_writeable_reg(struct device *dev, unsigned 
int reg)

  {
switch (reg) {
 @@ -410,6 +417,8 @@ static int 
ingenic_drm_plane_atomic_check(struct drm_plane *plane,
  	 old_plane_state->fb->format->format != 
new_plane_state->fb->format->format))

crtc_state->mode_changed = true;

 +  drm_atomic_helper_check_plane_damage(state, new_plane_state);
 +
return 0;
  }

 @@ -541,10 +550,20 @@ static void ingenic_drm_update_palette(struct 
ingenic_drm *priv,

}
  }

 +void ingenic_drm_sync_data(struct device *dev,
 + struct drm_plane_state *old_state,
 + struct drm_plane_state *state)
 +{
 +  if (ingenic_drm_cached_gem_buf)
 +  drm_gem_cma_sync_data(dev, old_state, state);
 +}
 +
  static void ingenic_drm_plane_atomic_update(struct drm_plane 
*plane,

struct drm_atomic_state *state)
  {
struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
 +	struct drm_plane_state *oldstate = 
drm_atomic_get_old_plane_state(state,

 +
plane);
  	struct drm_plane_state *newstate = 
drm_atomic_get_new_plane_state(state,

  
plane);
struct drm_crtc_state *crtc_state;
 @@ -554,6 +573,8 @@ static void 
ingenic_drm_plane_atomic_update(struct drm_plane *plane,

u32 fourcc;

if (newstate && newstate->fb) {
 +  ingenic_drm_sync_data(priv->dev, oldstate, newstate);
 +
crtc_state = newstate->crtc->state;

addr = drm_fb_cma_get_gem_addr(newstate->fb, newstate, 0);
 @@ -743,6 +764,26 @@ static void ingenic_drm_disable_vblank(struct 
drm_crtc *crtc)
  	regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, 
JZ_LCD_CTRL_EOF_IRQ, 0);

  }

 +static struct drm_framebuffer *
 +ingenic_drm_gem_fb_create(struct drm_device *dev, struct drm_file 
*file,

 +const struct drm_mode_fb_cmd2 *mode_cmd)
 +{
 +  if (ingenic_drm_cached_gem_buf)
 +  return drm_gem_fb_create_with_dirty(dev, file, mode_cmd);
 +
 +  return drm_gem_fb_create(dev, file, mode_cmd);
 +}
 +
 +static int ingenic_drm_gem_cma_dumb_create(struct drm_file 
*file_priv,

 + struct drm_device *drm,
 + struct drm_mode_create_dumb *args)
 +{
 +  if (ingenic_drm_cached_gem_buf)
 +  return drm_gem_cma_dumb_create_noncoherent(file_priv, drm, 
args);
 +
 +  return drm_gem_cma_dumb_create(f

Re: [PATCH v2 0/5] Add option to mmap GEM buffers cached

[Paul Cercueil]

Hi Thomas,

Le lun. 8 mars 2021 à 9:41, Thomas Zimmermann  a 
écrit :

Hi Paul,

having individual functions for each mode only makes sense if the 
decision is at compile time. But in patch 5, you're working around 
your earlier design by introducing in-driver helpers that select the 
correct CMA function.


In SHMEM helpers we have the flag map_wc in the GEM structure that 
selects the pages caching mode (wc vs uncached). I think CMA should 
use this design as well. Have a map_noncoherent flag in the CMA GEM 
object and set it from the driver's implementation of 
gem_create_object.


Is that a new addition? That severely reduces the patchset size, which 
is perfect.


I'll send a V3 then.

Cheers,
-Paul

And in the long run, we could try to consolidate all drivers/helpers 
mapping flags in struct drm_gem_object.


Best regards
Thomas

Am 07.03.21 um 21:28 schrieb Paul Cercueil:

Rework of my previous patchset which added support for GEM buffers
backed by non-coherent memory to the ingenic-drm driver.

Having GEM buffers backed by non-coherent memory is interesting in
the particular case where it is faster to render to a non-coherent
buffer then sync the data cache, than to render to a write-combine
buffer, and (by extension) much faster than using a shadow buffer.
This is true for instance on some Ingenic SoCs, where even simple
blits (e.g. memcpy) are about three times faster using this method.

For the record, the previous patchset was accepted for 5.10 then had
to be reverted, as it conflicted with some changes made to the DMA 
API.


This new patchset is pretty different as it adds the functionality to
the DRM core. The first three patches add variants to existing 
functions
but with the "non-coherent memory" twist, exported as GPL symbols. 
The

fourth patch adds a function to be used with the damage helpers.
Finally, the last patch adds support for non-coherent GEM buffers to 
the

ingenic-drm driver. The functionality is enabled through a module
parameter, and is disabled by default.

Cheers,
-Paul

Paul Cercueil (5):
   drm: Add and export function drm_gem_cma_create_noncoherent
   drm: Add and export function drm_gem_cma_dumb_create_noncoherent
   drm: Add and export function drm_gem_cma_mmap_noncoherent
   drm: Add and export function drm_gem_cma_sync_data
   drm/ingenic: Add option to alloc cached GEM buffers

  drivers/gpu/drm/drm_gem_cma_helper.c  | 223 
+++---

  drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  49 -
  drivers/gpu/drm/ingenic/ingenic-drm.h |   4 +
  drivers/gpu/drm/ingenic/ingenic-ipu.c |  14 +-
  include/drm/drm_gem_cma_helper.h  |  13 ++
  5 files changed, 273 insertions(+), 30 deletions(-)



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 3/6] drm/displayid: add new displayid section/block iterators

[Ville Syrjälä]

On Tue, Mar 09, 2021 at 03:54:11PM +0200, Jani Nikula wrote:
> Iterating DisplayID blocks across sections (in EDID extensions) is
> unnecessarily complicated for the caller. Implement DisplayID iterators
> to go through all blocks in all sections.
> 
> Usage example:
> 
>   const struct displayid_block *block;
>   struct displayid_iter iter;
> 
>   displayid_iter_edid_begin(edid, &iter);
>   displayid_iter_for_each(block, &iter) {
>   /* operate on block */
>   }
>   displayid_iter_end(&iter);
> 
> When DisplayID is stored in EDID extensions, the DisplayID sections map
> to extensions as described in VESA DisplayID v1.3 Appendix B: DisplayID
> as an EDID Extension. This is implemented here.
> 
> When DisplayID is stored in its dedicated DDC device 0xA4, according to
> VESA E-DDC v1.3, different rules apply for the structure. This is not
> implemented here, as we don't currently use it, but the idea is you'd
> have a different call for beginning the iteration, for example simply:
> 
>   displayid_iter_begin(displayid, &iter);
> 
> instead of displayid_iter_edid_begin(), and everything else would be
> hidden away in the iterator functions.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_displayid.c | 74 +
>  include/drm/drm_displayid.h | 18 
>  2 files changed, 92 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
> index 908bbe6feb61..88070267aac9 100644
> --- a/drivers/gpu/drm/drm_displayid.c
> +++ b/drivers/gpu/drm/drm_displayid.c
> @@ -57,3 +57,77 @@ const u8 *drm_find_displayid_extension(const struct edid 
> *edid,
>  
>   return displayid;
>  }
> +
> +void displayid_iter_edid_begin(const struct edid *edid,
> +struct displayid_iter *iter)
> +{
> + memset(iter, 0, sizeof(*iter));
> +
> + iter->edid = edid;
> +}
> +
> +static const struct displayid_block *
> +__displayid_iter_block(const struct displayid_iter *iter)
> +{
> + const struct displayid_block *block;
> +
> + if (!iter->section)
> + return NULL;
> +
> + block = (const struct displayid_block *)&iter->section[iter->idx];
> +
> + if (iter->idx + sizeof(struct displayid_block) <= iter->length &&
> + iter->idx + sizeof(struct displayid_block) + block->num_bytes <= 
> iter->length &&

sizeof(*block) perhaps

> + block->num_bytes > 0)
> + return block;
> +
> + return NULL;
> +}
> +
> +const struct displayid_block *
> +__displayid_iter_next(struct displayid_iter *iter)
> +{
> + const struct displayid_block *block;
> +
> + if (!iter->edid)
> + return NULL;
> +
> + if (iter->section) {
> + /* current block should always be valid */
> + block = __displayid_iter_block(iter);
> + if (WARN_ON(!block)) {
> + iter->section = NULL;
> + iter->edid = NULL;
> + return NULL;
> + }
> +
> + /* next block in section */
> + iter->idx += sizeof(struct displayid_block) + block->num_bytes;

ditto

Looks like this should do the same thing the current thing does,
or at least I couldn't immediately spot nay differences.

Reviewed-by: Ville Syrjälä 

> +
> + block = __displayid_iter_block(iter);
> + if (block)
> + return block;
> + }
> +
> + for (;;) {
> + iter->section = drm_find_displayid_extension(iter->edid,
> +  &iter->length,
> +  &iter->idx,
> +  &iter->ext_index);
> + if (!iter->section) {
> + iter->edid = NULL;
> + return NULL;
> + }
> +
> + iter->idx += sizeof(struct displayid_hdr);
> +
> + block = __displayid_iter_block(iter);
> + if (block)
> + return block;
> + }
> +}
> +
> +void displayid_iter_end(struct displayid_iter *iter)
> +{
> + memset(iter, 0, sizeof(*iter));
> +}
> diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
> index 3c6db22a518a..27e06c98db17 100644
> --- a/include/drm/drm_displayid.h
> +++ b/include/drm/drm_displayid.h
> @@ -108,4 +108,22 @@ const u8 *drm_find_displayid_extension(const struct edid 
> *edid,
>  int *length, int *idx,
>  int *ext_index);
>  
> +/* DisplayID iteration */
> +struct displayid_iter {
> + const struct edid *edid;
> +
> + const u8 *section;
> + int length;
> + int idx;
> + int ext_index;
> +};
> +
> +void displayid_iter_edid_begin(const struct edid *edid,
> +struct displayid_iter *iter);
> +const struct displayid_block *
> +__displayid_it

Re: [RFC v1 4/6] drm/edid: use the new displayid iterator for detailed modes

[Ville Syrjälä]

On Tue, Mar 09, 2021 at 03:54:12PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. No functional changes.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid.c | 23 ++-
>  1 file changed, 6 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 58e61f792bc7..fbaa7d679cb2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5333,27 +5333,16 @@ static int add_displayid_detailed_1_modes(struct 
> drm_connector *connector,
>  static int add_displayid_detailed_modes(struct drm_connector *connector,
>   struct edid *edid)
>  {
> - const u8 *displayid;
> - int length, idx;
>   const struct displayid_block *block;
> + struct displayid_iter iter;
>   int num_modes = 0;
> - int ext_index = 0;
> -
> - for (;;) {
> - displayid = drm_find_displayid_extension(edid, &length, &idx,
> -  &ext_index);
> - if (!displayid)
> - break;
>  
> - idx += sizeof(struct displayid_hdr);
> - for_each_displayid_db(displayid, block, idx, length) {
> - switch (block->tag) {
> - case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
> - num_modes += 
> add_displayid_detailed_1_modes(connector, block);
> - break;
> - }
> - }
> + displayid_iter_edid_begin(edid, &iter);
> + displayid_iter_for_each(block, &iter) {
> + if (block->tag == DATA_BLOCK_TYPE_1_DETAILED_TIMING)
> + num_modes += add_displayid_detailed_1_modes(connector, 
> block);
>   }
> + displayid_iter_end(&iter);
>  
>   return num_modes;
>  }
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: don't base trees on 5.12-rc1

[Dave Airlie]

On Wed, 10 Mar 2021 at 17:48, Maxime Ripard  wrote:
>
> Hi Dave,
>
> On Wed, Mar 10, 2021 at 09:50:29AM +1000, Dave Airlie wrote:
> > I'm mostly sending this to the -misc maintainers because
> > drm-misc-fixes is based on rc1 at present.
> >
> > This needs to be *rebased* not merged up to 5.12-rc2. Merging will
> > still have the bad landmine commits in the bisect history. This is a
> > very special case.
>
> I'm sorry, I'm not entirely sure I get this. -rc1 is still in the -rc2
> history, so how would that change anything in the bisect history?
>

We can't get rid of the bad commit range, we can reduce the amount of
times someone accidentally bisects into it, by not using it as a base
commit for future changes.

If in the future a bisect happens to want to test one of the patches
in drm-misc-fixes that is based on rc1, it will land the user with an
rc1 test kernel and could eat their swapfile/disk. We can avoid that
problem by not using rc1 as a base for drm-misc-fixes.

We can't avoid them bisecting into the broken commits between when
this landed and was fixed, but rebasing trees can minimise the chances
of this when bisecting other changesets.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v1 5/6] drm/edid: use the new displayid iterator for finding CEA extension

[Ville Syrjälä]

On Tue, Mar 09, 2021 at 03:54:13PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. No functional changes.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c | 25 +
>  1 file changed, 9 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index fbaa7d679cb2..4526e2557dca 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3266,35 +3266,28 @@ const u8 *drm_find_edid_extension(const struct edid 
> *edid,
>  
>  static const u8 *drm_find_cea_extension(const struct edid *edid)
>  {
> - int length, idx;
>   const struct displayid_block *block;
> + struct displayid_iter iter;
>   const u8 *cea;
> - const u8 *displayid;
> - int ext_index;
> + int ext_index = 0;
>  
>   /* Look for a top level CEA extension block */
>   /* FIXME: make callers iterate through multiple CEA ext blocks? */
> - ext_index = 0;
>   cea = drm_find_edid_extension(edid, CEA_EXT, &ext_index);
>   if (cea)
>   return cea;
>  
>   /* CEA blocks can also be found embedded in a DisplayID block */
> - ext_index = 0;
> - for (;;) {
> - displayid = drm_find_displayid_extension(edid, &length, &idx,
> -  &ext_index);
> - if (!displayid)
> - return NULL;
> -
> - idx += sizeof(struct displayid_hdr);
> - for_each_displayid_db(displayid, block, idx, length) {
> - if (block->tag == DATA_BLOCK_CTA)
> - return (const u8 *)block;
> + displayid_iter_edid_begin(edid, &iter);
> + displayid_iter_for_each(block, &iter) {
> + if (block->tag == DATA_BLOCK_CTA) {
> + cea = (const u8 *)block;
> + break;
>   }
>   }
> + displayid_iter_end(&iter);
>  
> - return NULL;
> + return cea;
>  }
>  
>  static __always_inline const struct drm_display_mode *cea_mode_for_vic(u8 
> vic)
> -- 
> 2.20.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [RFC v1 6/6] drm/edid: use the new displayid iterator for tile info

[Ville Syrjälä]

On Tue, Mar 09, 2021 at 03:54:14PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. Remove excessive debug
> logging while at it, no other functional changes.
> 
> The old displayid iterator becomes unused; remove it as well as make
> drm_find_displayid_extension() static.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

Hopeuflly you tested with some of those weird EDIDs with
multiple DisplayID and/or CEA blocks ;)

I was thinking we should try to coalesce an iterator for
the CEA stuff as well...

> ---
>  drivers/gpu/drm/drm_displayid.c |  6 +++---
>  drivers/gpu/drm/drm_edid.c  | 37 +++--
>  include/drm/drm_displayid.h | 12 ---
>  3 files changed, 10 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
> index 88070267aac9..b146f2d0d72a 100644
> --- a/drivers/gpu/drm/drm_displayid.c
> +++ b/drivers/gpu/drm/drm_displayid.c
> @@ -33,9 +33,9 @@ static int validate_displayid(const u8 *displayid, int 
> length, int idx)
>   return 0;
>  }
>  
> -const u8 *drm_find_displayid_extension(const struct edid *edid,
> -int *length, int *idx,
> -int *ext_index)
> +static const u8 *drm_find_displayid_extension(const struct edid *edid,
> +   int *length, int *idx,
> +   int *ext_index)
>  {
>   const u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, 
> ext_index);
>   const struct displayid_hdr *base;
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 4526e2557dca..81d5f2524246 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5969,43 +5969,20 @@ static void drm_parse_tiled_block(struct 
> drm_connector *connector,
>   }
>  }
>  
> -static void drm_displayid_parse_tiled(struct drm_connector *connector,
> -   const u8 *displayid, int length, int idx)
> -{
> - const struct displayid_block *block;
> -
> - idx += sizeof(struct displayid_hdr);
> - for_each_displayid_db(displayid, block, idx, length) {
> - DRM_DEBUG_KMS("block id 0x%x, rev %d, len %d\n",
> -   block->tag, block->rev, block->num_bytes);
> -
> - switch (block->tag) {
> - case DATA_BLOCK_TILED_DISPLAY:
> - drm_parse_tiled_block(connector, block);
> - break;
> - default:
> - DRM_DEBUG_KMS("found DisplayID tag 0x%x, unhandled\n", 
> block->tag);
> - break;
> - }
> - }
> -}
> -
>  void drm_update_tile_info(struct drm_connector *connector,
> const struct edid *edid)
>  {
> - const void *displayid = NULL;
> - int ext_index = 0;
> - int length, idx;
> + const struct displayid_block *block;
> + struct displayid_iter iter;
>  
>   connector->has_tile = false;
> - for (;;) {
> - displayid = drm_find_displayid_extension(edid, &length, &idx,
> -  &ext_index);
> - if (!displayid)
> - break;
>  
> - drm_displayid_parse_tiled(connector, displayid, length, idx);
> + displayid_iter_edid_begin(edid, &iter);
> + displayid_iter_for_each(block, &iter) {
> + if (block->tag == DATA_BLOCK_TILED_DISPLAY)
> + drm_parse_tiled_block(connector, block);
>   }
> + displayid_iter_end(&iter);
>  
>   if (!connector->has_tile && connector->tile_group) {
>   drm_mode_put_tile_group(connector->dev, connector->tile_group);
> diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
> index 27e06c98db17..10ee863f1734 100644
> --- a/include/drm/drm_displayid.h
> +++ b/include/drm/drm_displayid.h
> @@ -96,18 +96,6 @@ struct displayid_detailed_timing_block {
>   struct displayid_detailed_timings_1 timings[];
>  };
>  
> -#define for_each_displayid_db(displayid, block, idx, length) \
> - for ((block) = (const struct displayid_block *)&(displayid)[idx]; \
> -  (idx) + sizeof(struct displayid_block) <= (length) && \
> -  (idx) + sizeof(struct displayid_block) + (block)->num_bytes <= 
> (length) && \
> -  (block)->num_bytes > 0; \
> -  (idx) += sizeof(struct displayid_block) + (block)->num_bytes, \
> -  (block) = (const struct displayid_block *)&(displayid)[idx])
> -
> -const u8 *drm_find_displayid_extension(const struct edid *edid,
> -int *length, int *idx,
> -int *ext_index);
> -
>  /* DisplayID iteration */
>  struct displayid_iter {
>   const struct edid *edid;
> -- 
> 2.20.1
> 
> ___
> Intel-gfx mailing list
> intel-.

Re: [PATCH v5 12/14] drm/bridge: imx: Add LDB support for i.MX8qxp

[kernel test robot]

Hi Liu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on robh/for-next drm-intel/for-linux-next 
drm-tip/drm-tip tegra-drm/drm/tegra/for-next linus/master 
drm-exynos/exynos-drm-next v5.12-rc2 next-20210310]
[cannot apply to drm/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/0day-ci/linux/commits/Liu-Ying/Add-some-DRM-bridge-drivers-support-for-i-MX8qm-qxp-SoCs/20210310-181047
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git 
for-next
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/e621f277f533f302da23441f28b3fc02a152a7df
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Liu-Ying/Add-some-DRM-bridge-drivers-support-for-i-MX8qm-qxp-SoCs/20210310-181047
git checkout e621f277f533f302da23441f28b3fc02a152a7df
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

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

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:16: warning: 'struct 
phy_configure_opts_lvds' declared inside parameter list will not be visible 
outside of this definition or declaration
  65 | struct phy_configure_opts_lvds *phy_cfg)
 |^~~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_set_phy_cfg':
>> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:67:9: error: dereferencing 
>> pointer to incomplete type 'struct phy_configure_opts_lvds'
  67 |  phy_cfg->bits_per_lane_and_dclk_cycle = 7;
 | ^~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_bridge_atomic_check':
>> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:94:49: error: 'union 
>> phy_configure_opts' has no member named 'lvds'
  94 |  struct phy_configure_opts_lvds *phy_cfg = &opts.lvds;
 | ^
>> drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:102:57: error: passing argument 
>> 4 of 'imx8qxp_ldb_set_phy_cfg' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
 102 |  imx8qxp_ldb_set_phy_cfg(imx8qxp_ldb, di_clk, is_split, phy_cfg);
 | ^~~
 | |
 | struct 
phy_configure_opts_lvds *
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:41: note: expected 'struct 
phy_configure_opts_lvds *' but argument is of type 'struct 
phy_configure_opts_lvds *'
  65 | struct phy_configure_opts_lvds *phy_cfg)
 | ^~~
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c: In function 
'imx8qxp_ldb_bridge_mode_set':
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:136:49: error: 'union 
phy_configure_opts' has no member named 'lvds'
 136 |  struct phy_configure_opts_lvds *phy_cfg = &opts.lvds;
 | ^
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:162:57: error: passing argument 
4 of 'imx8qxp_ldb_set_phy_cfg' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 162 |  imx8qxp_ldb_set_phy_cfg(imx8qxp_ldb, di_clk, is_split, phy_cfg);
 | ^~~
 | |
 | struct 
phy_configure_opts_lvds *
   drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c:65:41: note: expected 'struct 
phy_configure_opts_lvds *' but argument is of type 'struct 
phy_configure_opts_lvds *'
  65 | struct phy_configure_opts_lvds *phy_cfg)
 | ^~~
   cc1: some warnings being treated as errors


vim +67 drivers/gpu/drm/bridge/imx/imx8qxp-ldb-drv.c

62  
63  static void imx8qxp_ldb_set_phy_cfg(struct imx8qxp_ldb *imx8qxp_ldb,
64  unsigned long di_clk, bool is_split,
65 

[Bug 212077] AMD GPU discrete card memory at highest frequency even while not in use

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=212077

--- Comment #5 from Bat Malin (bat_ma...@abv.bg) ---
Issue still present in 5.11.5
 1.335057] amdgpu: Clock is not in range of specified clock range for watermark
from DAL!  Using highest water mark set.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 212077] AMD GPU discrete card memory at highest frequency even while not in use

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=212077

--- Comment #6 from Bat Malin (bat_ma...@abv.bg) ---
No change in the code of 5.12-rc2...

for (i = 0; i < dep_mclk_table->count; i++) {
for (j = 0; j < dep_sclk_table->count; j++) {
valid_entry = false;
for (k = 0; k < watermarks->num_wm_sets; k++) {
if (dep_sclk_table->entries[i].clk / 10 >=
watermarks->wm_clk_ranges[k].wm_min_eng_clk_in_khz &&
dep_sclk_table->entries[i].clk / 10 <
watermarks->wm_clk_ranges[k].wm_max_eng_clk_in_khz &&
dep_mclk_table->entries[i].clk / 10 >=
watermarks->wm_clk_ranges[k].wm_min_mem_clk_in_khz &&
dep_mclk_table->entries[i].clk / 10 <
watermarks->wm_clk_ranges[k].wm_max_mem_clk_in_khz) {
valid_entry = true;
table->DisplayWatermark[i][j] =
watermarks->wm_clk_ranges[k].wm_set_id;
break;

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] i915: Drop legacy execbuffer support

[Jason Ekstrand]

libdrm has supported the newer execbuffer2 ioctl and using it by default
when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
which landed Mar 2, 2010.  The i915 and i965 drivers in Mesa at the time
both used libdrm and so did the Intel X11 back-end.  The SNA back-end
for X11 has always used execbuffer2.

Signed-off-by: Jason Ekstrand 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 100 --
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 -
 drivers/gpu/drm/i915/i915_drv.c   |   2 +-
 3 files changed, 1 insertion(+), 103 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index fe170186dd428..99772f37bff60 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3394,106 +3394,6 @@ static bool check_buffer_count(size_t count)
return !(count < 1 || count > INT_MAX || count > SIZE_MAX / sz - 1);
 }
 
-/*
- * Legacy execbuffer just creates an exec2 list from the original exec object
- * list array and passes it to the real function.
- */
-int
-i915_gem_execbuffer_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file)
-{
-   struct drm_i915_private *i915 = to_i915(dev);
-   struct drm_i915_gem_execbuffer *args = data;
-   struct drm_i915_gem_execbuffer2 exec2;
-   struct drm_i915_gem_exec_object *exec_list = NULL;
-   struct drm_i915_gem_exec_object2 *exec2_list = NULL;
-   const size_t count = args->buffer_count;
-   unsigned int i;
-   int err;
-
-   if (!check_buffer_count(count)) {
-   drm_dbg(&i915->drm, "execbuf2 with %zd buffers\n", count);
-   return -EINVAL;
-   }
-
-   exec2.buffers_ptr = args->buffers_ptr;
-   exec2.buffer_count = args->buffer_count;
-   exec2.batch_start_offset = args->batch_start_offset;
-   exec2.batch_len = args->batch_len;
-   exec2.DR1 = args->DR1;
-   exec2.DR4 = args->DR4;
-   exec2.num_cliprects = args->num_cliprects;
-   exec2.cliprects_ptr = args->cliprects_ptr;
-   exec2.flags = I915_EXEC_RENDER;
-   i915_execbuffer2_set_context_id(exec2, 0);
-
-   err = i915_gem_check_execbuffer(&exec2);
-   if (err)
-   return err;
-
-   /* Copy in the exec list from userland */
-   exec_list = kvmalloc_array(count, sizeof(*exec_list),
-  __GFP_NOWARN | GFP_KERNEL);
-
-   /* Allocate extra slots for use by the command parser */
-   exec2_list = kvmalloc_array(count + 2, eb_element_size(),
-   __GFP_NOWARN | GFP_KERNEL);
-   if (exec_list == NULL || exec2_list == NULL) {
-   drm_dbg(&i915->drm,
-   "Failed to allocate exec list for %d buffers\n",
-   args->buffer_count);
-   kvfree(exec_list);
-   kvfree(exec2_list);
-   return -ENOMEM;
-   }
-   err = copy_from_user(exec_list,
-u64_to_user_ptr(args->buffers_ptr),
-sizeof(*exec_list) * count);
-   if (err) {
-   drm_dbg(&i915->drm, "copy %d exec entries failed %d\n",
-   args->buffer_count, err);
-   kvfree(exec_list);
-   kvfree(exec2_list);
-   return -EFAULT;
-   }
-
-   for (i = 0; i < args->buffer_count; i++) {
-   exec2_list[i].handle = exec_list[i].handle;
-   exec2_list[i].relocation_count = exec_list[i].relocation_count;
-   exec2_list[i].relocs_ptr = exec_list[i].relocs_ptr;
-   exec2_list[i].alignment = exec_list[i].alignment;
-   exec2_list[i].offset = exec_list[i].offset;
-   if (INTEL_GEN(to_i915(dev)) < 4)
-   exec2_list[i].flags = EXEC_OBJECT_NEEDS_FENCE;
-   else
-   exec2_list[i].flags = 0;
-   }
-
-   err = i915_gem_do_execbuffer(dev, file, &exec2, exec2_list);
-   if (exec2.flags & __EXEC_HAS_RELOC) {
-   struct drm_i915_gem_exec_object __user *user_exec_list =
-   u64_to_user_ptr(args->buffers_ptr);
-
-   /* Copy the new buffer offsets back to the user's exec list. */
-   for (i = 0; i < args->buffer_count; i++) {
-   if (!(exec2_list[i].offset & UPDATE))
-   continue;
-
-   exec2_list[i].offset =
-   gen8_canonical_addr(exec2_list[i].offset & 
PIN_OFFSET_MASK);
-   exec2_list[i].offset &= PIN_OFFSET_MASK;
-   if (__copy_to_user(&user_exec_list[i].offset,
-  &exec2_list[i].offset,
-  sizeof(user_exec_list[i].offset)))
-   brea

Re: [PATCH v6 5/9] clk: stm32: Fix stm32f429's ltdc driver hang in set clock rate

[dillon min]

still need more expert to review, so just a gentle ping for this patch

On Wed, May 27, 2020 at 4:35 PM Stephen Boyd  wrote:
>
> Quoting dillon.min...@gmail.com (2020-05-27 00:27:29)
> > From: dillon min 
> >
> > This is due to misuse \u2018PLL_VCO_SAI' and'PLL_SAI' in clk-stm32f4.c
> > 'PLL_SAI' is 2, 'PLL_VCO_SAI' is 7(defined in
> > include/dt-bindings/clock/stm32fx-clock.h).
> >
> > 'post_div' point to 'post_div_data[]', 'post_div->pll_num'
> > is PLL_I2S or PLL_SAI.
> >
> > 'clks[PLL_VCO_SAI]' has valid 'struct clk_hw* ' return
> > from stm32f4_rcc_register_pll() but, at line 1777 of
> > driver/clk/clk-stm32f4.c, use the 'clks[post_div->pll_num]',
> > equal to 'clks[PLL_SAI]', this is invalid array member at that time.
> >
> > Fixes: 517633ef630e ("clk: stm32f4: Add post divisor for I2S & SAI PLLs")
> > Signed-off-by: dillon min 
> > ---
>
> Acked-by: Stephen Boyd 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/9] powerpc/pseries: remove the ppc-cmm file system

[Al Viro]

On Tue, Mar 09, 2021 at 04:53:42PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.

Umm...  The only problem I see here is the lifetime rules for
that module, and that's not something introduced in this patchset.
Said that, looks like the logics around that place is duplicated in
cmm.c, vmw_balloon.c and virtion_balloon.c and I wonder if it would
be better off with a helper in mm/balloon.c to be used for that setup...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] fb_defio: Remove custom address_space_operations

[William Kucharski]

Looks good, just one super minor nit inline.

Reviewed-by: William Kucharski 

> On Mar 10, 2021, at 6:51 AM, Matthew Wilcox (Oracle)  
> wrote:
> 
> There's no need to give the page an address_space.  Leaving the
> page->mapping as NULL will cause the VM to handle set_page_dirty()
> the same way that it's set now, and that was the only reason to
> set the address_space in the first place.
> 
> Signed-off-by: Matthew Wilcox (Oracle) 
> ---
> drivers/video/fbdev/core/fb_defio.c | 33 -
> drivers/video/fbdev/core/fbmem.c|  4 
> include/linux/fb.h  |  3 ---
> 3 files changed, 40 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fb_defio.c 
> b/drivers/video/fbdev/core/fb_defio.c
> index a591d291b231..1bb208b3c4bb 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -52,13 +52,6 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault 
> *vmf)
>   return VM_FAULT_SIGBUS;
> 
>   get_page(page);
> -
> - if (vmf->vma->vm_file)
> - page->mapping = vmf->vma->vm_file->f_mapping;
> - else
> - printk(KERN_ERR "no mapping available\n");
> -
> - BUG_ON(!page->mapping);
>   page->index = vmf->pgoff;
> 
>   vmf->page = page;
> @@ -151,17 +144,6 @@ static const struct vm_operations_struct 
> fb_deferred_io_vm_ops = {
>   .page_mkwrite   = fb_deferred_io_mkwrite,
> };
> 
> -static int fb_deferred_io_set_page_dirty(struct page *page)
> -{
> - if (!PageDirty(page))
> - SetPageDirty(page);
> - return 0;
> -}
> -
> -static const struct address_space_operations fb_deferred_io_aops = {
> - .set_page_dirty = fb_deferred_io_set_page_dirty,
> -};
> -
> int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
> {
>   vma->vm_ops = &fb_deferred_io_vm_ops;
> @@ -212,14 +194,6 @@ void fb_deferred_io_init(struct fb_info *info)
> }
> EXPORT_SYMBOL_GPL(fb_deferred_io_init);
> 
> -void fb_deferred_io_open(struct fb_info *info,
> -  struct inode *inode,
> -  struct file *file)
> -{
> - file->f_mapping->a_ops = &fb_deferred_io_aops;
> -}
> -EXPORT_SYMBOL_GPL(fb_deferred_io_open);
> -
> void fb_deferred_io_cleanup(struct fb_info *info)
> {
>   struct fb_deferred_io *fbdefio = info->fbdefio;
> @@ -228,13 +202,6 @@ void fb_deferred_io_cleanup(struct fb_info *info)
> 
>   BUG_ON(!fbdefio);
>   cancel_delayed_work_sync(&info->deferred_work);
> -
> - /* clear out the mapping that we setup */
> - for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
> - page = fb_deferred_io_page(info, i);
> - page->mapping = NULL;
> - }
> -
>   mutex_destroy(&fbdefio->lock);
> }

We no longer need the definition of "int i" right before the BUG_ON().

> EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
> diff --git a/drivers/video/fbdev/core/fbmem.c 
> b/drivers/video/fbdev/core/fbmem.c
> index 06f5805de2de..372b52a2befa 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1415,10 +1415,6 @@ __releases(&info->lock)
>   if (res)
>   module_put(info->fbops->owner);
>   }
> -#ifdef CONFIG_FB_DEFERRED_IO
> - if (info->fbdefio)
> - fb_deferred_io_open(info, inode, file);
> -#endif
> out:
>   unlock_fb_info(info);
>   if (res)
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index ecfbcc0553a5..a8dccd23c249 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -659,9 +659,6 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
> d_pitch,
> /* drivers/video/fb_defio.c */
> int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
> extern void fb_deferred_io_init(struct fb_info *info);
> -extern void fb_deferred_io_open(struct fb_info *info,
> - struct inode *inode,
> - struct file *file);
> extern void fb_deferred_io_cleanup(struct fb_info *info);
> extern int fb_deferred_io_fsync(struct file *file, loff_t start,
>   loff_t end, int datasync);
> -- 
> 2.30.0
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 6/9] clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after kernel startup

[dillon min]

still need more expert to review, so just a gentle ping for this patch

On Wed, May 27, 2020 at 4:35 PM Stephen Boyd  wrote:
>
> Quoting dillon.min...@gmail.com (2020-05-27 00:27:30)
> > From: dillon min 
> >
> > stm32's clk driver register two ltdc gate clk to clk core by
> > clk_hw_register_gate() and clk_hw_register_composite()
> >
> > first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use.
> > second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver
> >
> > both of them point to the same offset of stm32's RCC register. after
> > kernel enter console, clk core turn off ltdc's clk as 'stm32f429_gates[]'
> > is no one to use. but, actually 'stm32f429_aux_clk[]' is in use.
> >
> > Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock")
> > Signed-off-by: dillon min 
> > ---
>
> Acked-by: Stephen Boyd 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/9] drm: remove the drm file system

[Al Viro]

On Tue, Mar 09, 2021 at 04:53:43PM +0100, Christoph Hellwig wrote:
> Just use the generic anon_inode file system.

Are you changing the lifetime rules for that module?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915/gem: Use user_write_access_begin() instead of user_access_begin()

[Christophe Leroy]

eb_copy_relocations() only do unsafe_put_user(), it only
requires write access to user.

Use user_write_access_begin() instead of user_access_begin().

Signed-off-by: Christophe Leroy 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index d70ca36f74f6..eb7a4bfd53ef 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1851,14 +1851,14 @@ static int eb_copy_relocations(const struct 
i915_execbuffer *eb)
 * happened we would make the mistake of assuming that the
 * relocations were valid.
 */
-   if (!user_access_begin(urelocs, size))
+   if (!user_write_access_begin(urelocs, size))
goto end;
 
for (copied = 0; copied < nreloc; copied++)
unsafe_put_user(-1,
&urelocs[copied].presumed_offset,
end_user);
-   user_access_end();
+   user_write_access_end();
 
eb->exec[i].relocs_ptr = (uintptr_t)relocs;
}
@@ -1866,7 +1866,7 @@ static int eb_copy_relocations(const struct 
i915_execbuffer *eb)
return 0;
 
 end_user:
-   user_access_end();
+   user_write_access_end();
 end:
kvfree(relocs);
err = -EFAULT;
-- 
2.25.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] i915: Drop relocation support on all new hardware

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+.  The
compute driver also never uses relocations.  This only leaves the media
driver which is supposed to be switching to softpin going forward.
Making softpin a requirement for all future hardware seems reasonable.

Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory.  Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.

Signed-off-by: Jason Ekstrand 
Cc: Dave Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 99772f37bff60..de093acb7721c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct 
eb_vma *ev)
return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+const struct drm_i915_gem_exec_object2 *entry)
 {
const char __user *addr, *end;
unsigned long size;
@@ -1774,6 +1775,13 @@ static int check_relocations(const struct 
drm_i915_gem_exec_object2 *entry)
if (size == 0)
return 0;
 
+   /* Relocations are disallowed for all platforms after TGL-LP */
+   if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+   return -EINVAL;
+
+   /* All discrete memory platforms are Gen12 or above */
+   BUG_ON(HAS_LMEM(eb->i915));
+
if (size > N_RELOC(ULONG_MAX))
return -EINVAL;
 
@@ -1807,7 +1815,7 @@ static int eb_copy_relocations(const struct 
i915_execbuffer *eb)
if (nreloc == 0)
continue;
 
-   err = check_relocations(&eb->exec[i]);
+   err = check_relocations(eb, &eb->exec[i]);
if (err)
goto err;
 
@@ -1880,7 +1888,7 @@ static int eb_prefault_relocations(const struct 
i915_execbuffer *eb)
for (i = 0; i < count; i++) {
int err;
 
-   err = check_relocations(&eb->exec[i]);
+   err = check_relocations(eb, &eb->exec[i]);
if (err)
return err;
}
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/i915/dp_link_training: Add newlines to debug messages

[Sean Paul]

From: Sean Paul 

This patch adds some newlines which are missing from debug messages.
This will prevent logs from being stacked up in dmesg.

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_link_training.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 892d7db7d94f..ad02d493ec16 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -29,7 +29,7 @@ static void
 intel_dp_dump_link_status(const u8 link_status[DP_LINK_STATUS_SIZE])
 {
 
-   DRM_DEBUG_KMS("ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x 
adj_req0_1:0x%x adj_req2_3:0x%x",
+   DRM_DEBUG_KMS("ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x 
adj_req0_1:0x%x adj_req2_3:0x%x\n",
  link_status[0], link_status[1], link_status[2],
  link_status[3], link_status[4], link_status[5]);
 }
@@ -731,7 +731,7 @@ intel_dp_link_train_phy(struct intel_dp *intel_dp,
 
 out:
drm_dbg_kms(&dp_to_i915(intel_dp)->drm,
-   "[CONNECTOR:%d:%s] Link Training %s at link rate = %d, lane 
count = %d, at %s",
+   "[CONNECTOR:%d:%s] Link Training %s at link rate = %d, lane 
count = %d, at %s\n",
intel_connector->base.base.id,
intel_connector->base.name,
ret ? "passed" : "failed",
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/i915/dp_link_training: Convert DRM_DEBUG_KMS to drm_dbg_kms

[Sean Paul]

From: Sean Paul 

One instance of DRM_DEBUG_KMS was leftover in dp_link_training, convert
it to the new shiny.

Signed-off-by: Sean Paul 
---
 .../gpu/drm/i915/display/intel_dp_link_training.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index ad02d493ec16..19ba7c7cbaab 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -26,12 +26,13 @@
 #include "intel_dp_link_training.h"
 
 static void
-intel_dp_dump_link_status(const u8 link_status[DP_LINK_STATUS_SIZE])
+intel_dp_dump_link_status(struct drm_device *drm,
+ const u8 link_status[DP_LINK_STATUS_SIZE])
 {
-
-   DRM_DEBUG_KMS("ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x 
adj_req0_1:0x%x adj_req2_3:0x%x\n",
- link_status[0], link_status[1], link_status[2],
- link_status[3], link_status[4], link_status[5]);
+   drm_dbg_kms(drm,
+   "ln0_1:0x%x ln2_3:0x%x align:0x%x sink:0x%x adj_req0_1:0x%x 
adj_req2_3:0x%x\n",
+   link_status[0], link_status[1], link_status[2],
+   link_status[3], link_status[4], link_status[5]);
 }
 
 static void intel_dp_reset_lttpr_count(struct intel_dp *intel_dp)
@@ -642,7 +643,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp 
*intel_dp,
/* Make sure clock is still ok */
if (!drm_dp_clock_recovery_ok(link_status,
  crtc_state->lane_count)) {
-   intel_dp_dump_link_status(link_status);
+   intel_dp_dump_link_status(&i915->drm, link_status);
drm_dbg_kms(&i915->drm,
"Clock recovery check failed, cannot "
"continue channel equalization\n");
@@ -669,7 +670,7 @@ intel_dp_link_training_channel_equalization(struct intel_dp 
*intel_dp,
 
/* Try 5 times, else fail and try at lower BW */
if (tries == 5) {
-   intel_dp_dump_link_status(link_status);
+   intel_dp_dump_link_status(&i915->drm, link_status);
drm_dbg_kms(&i915->drm,
"Channel equalization failed 5 times\n");
}
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations.  The older i965
driver in Mesa does use relocations but it only supports Intel hardware
through Gen11 and has been deprecated for all hardware Gen9+.  The
compute driver also never uses relocations.  This only leaves the media
driver which is supposed to be switching to softpin going forward.
Making softpin a requirement for all future hardware seems reasonable.

Rejecting relocations starting with Gen12 has the benefit that we don't
have to bother supporting it on platforms with local memory.  Given how
much CPU touching of memory is required for relocations, not having to
do so on platforms where not all memory is directly CPU-accessible
carries significant advantages.

v2 (Jason Ekstrand):
 - Allow TGL-LP platforms as they've already shipped

v3 (Jason Ekstrand):
 - WARN_ON platforms with LMEM support in case the check is wrong

Signed-off-by: Jason Ekstrand 
Cc: Dave Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 99772f37bff60..b02dbd16bfa03 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct 
eb_vma *ev)
return err;
 }
 
-static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
+static int check_relocations(const struct i915_execbuffer *eb,
+const struct drm_i915_gem_exec_object2 *entry)
 {
const char __user *addr, *end;
unsigned long size;
@@ -1774,6 +1775,14 @@ static int check_relocations(const struct 
drm_i915_gem_exec_object2 *entry)
if (size == 0)
return 0;
 
+   /* Relocations are disallowed for all platforms after TGL-LP */
+   if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
+   return -EINVAL;
+
+   /* All discrete memory platforms are Gen12 or above */
+   if (WARN_ON(HAS_LMEM(eb->i915)))
+   return -EINVAL;
+
if (size > N_RELOC(ULONG_MAX))
return -EINVAL;
 
@@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct 
i915_execbuffer *eb)
if (nreloc == 0)
continue;
 
-   err = check_relocations(&eb->exec[i]);
+   err = check_relocations(eb, &eb->exec[i]);
if (err)
goto err;
 
@@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct 
i915_execbuffer *eb)
for (i = 0; i < count; i++) {
int err;
 
-   err = check_relocations(&eb->exec[i]);
+   err = check_relocations(eb, &eb->exec[i]);
if (err)
return err;
}
-- 
2.29.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu, radeon drm-fixes-5.12

[Alex Deucher]

Hi Dave, Daniel,

Fixes for 5.12.

The following changes since commit 1aa46901ee51c1c5779b3b239ea0374a50c6d9ff:

  drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcie 
(2021-03-03 23:05:16 -0500)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-fixes-5.12-2021-03-10

for you to fetch changes up to a5cb3c1a36376c25cd25fd3e99918dc48ac420bb:

  drm/amdgpu: fix S0ix handling when the CONFIG_AMD_PMC=m (2021-03-10 16:23:26 
-0500)


amd-drm-fixes-5.12-2021-03-10:

amdgpu:
- Fix aux backlight control
- Add a backlight override parameter
- Various display fixes
- PCIe DPM fix for vega
- Polaris watermark fixes
- Additional S0ix fix

radeon:
- Fix GEM regression
- Fix AGP dependency handling


Alex Deucher (4):
  drm/amdgpu/display: simplify backlight setting
  drm/amdgpu/display: don't assert in set backlight function
  drm/amdgpu/display: handle aux backlight in backlight_get_brightness
  drm/amdgpu: fix S0ix handling when the CONFIG_AMD_PMC=m

Christian König (2):
  drm/radeon: also init GEM funcs in radeon_gem_prime_import_sg_table
  drm/radeon: fix AGP dependency

Dillon Varone (1):
  drm/amd/display: Enabled pipe harvesting in dcn30

Evan Quan (1):
  drm/amd/pm: correct the watermark settings for Polaris

Holger Hoffstätte (2):
  drm/amd/display: Fix nested FPU context in dcn21_validate_bandwidth()
  drm/amdgpu/display: use GFP_ATOMIC in dcn21_validate_bandwidth_fp()

Kenneth Feng (1):
  drm/amd/pm: bug fix for pcie dpm

Nirmoy Das (1):
  drm/amdgpu: fb BO should be ttm_bo_type_device

Qingqing Zhuo (1):
  drm/amd/display: Enable pflip interrupt upon pipe enable

Sung Lee (1):
  drm/amd/display: Revert dram_clock_change_latency for DCN2.1

Takashi Iwai (1):
  drm/amd/display: Add a backlight module option

Zhan Liu (1):
  drm/amdgpu/display: Use wm_table.entries for dcn301 calculate_wm

 drivers/gpu/drm/Kconfig|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  2 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 50 ++-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c  |  1 -
 drivers/gpu/drm/amd/display/dc/dc.h|  1 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.c  | 11 +++
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h  |  6 ++
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  |  7 ++
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hubp.c  |  1 +
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c |  6 ++
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c  |  1 +
 .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c  |  8 +-
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c  |  1 +
 .../gpu/drm/amd/display/dc/dcn30/dcn30_resource.c  | 31 +++
 .../drm/amd/display/dc/dcn301/dcn301_resource.c| 96 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/hubp.h   |  2 +
 .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c|  8 +-
 .../gpu/drm/amd/pm/powerplay/hwmgr/vega10_hwmgr.c  | 48 +++
 .../gpu/drm/amd/pm/powerplay/hwmgr/vega12_hwmgr.c  | 66 +++
 .../gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.c  | 48 ++-
 drivers/gpu/drm/radeon/radeon.h|  2 +
 drivers/gpu/drm/radeon/radeon_gem.c|  4 +-
 drivers/gpu/drm/radeon/radeon_prime.c  |  2 +
 26 files changed, 353 insertions(+), 57 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

[Felix Kuehling]

On 2021-03-09 11:50 a.m., Felix Kuehling wrote:

Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:

x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
`kfd_iommu_bind_process_to_device':
kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to 
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to 
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to 
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to 
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to 
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to 
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to 
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to 
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to 
`amd_iommu_free_device'

Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.

Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it 
conditional")
Reported-by: Arnd Bergmann 
Signed-off-by: Felix Kuehling 

Ping. Can I get an R-b for this patch.

Thanks,
  Felix



---
  drivers/gpu/drm/amd/amdkfd/kfd_iommu.c | 6 ++
  drivers/gpu/drm/amd/amdkfd/kfd_iommu.h | 9 +++--
  2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
index 66bbca61e3ef..9318936aa805 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
@@ -20,6 +20,10 @@
   * OTHER DEALINGS IN THE SOFTWARE.
   */
  
+#include 

+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
+
  #include 
  #include 
  #include 
@@ -355,3 +359,5 @@ int kfd_iommu_add_perf_counters(struct kfd_topology_device 
*kdev)
  
  	return 0;

  }
+
+#endif
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
index dd23d9fdf6a8..afd420b01a0c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_iommu.h
@@ -23,7 +23,9 @@
  #ifndef __KFD_IOMMU_H__
  #define __KFD_IOMMU_H__
  
-#if defined(CONFIG_AMD_IOMMU_V2_MODULE) || defined(CONFIG_AMD_IOMMU_V2)

+#include 
+
+#if IS_REACHABLE(CONFIG_AMD_IOMMU_V2)
  
  #define KFD_SUPPORT_IOMMU_V2
  
@@ -46,6 +48,9 @@ static inline int kfd_iommu_check_device(struct kfd_dev *kfd)

  }
  static inline int kfd_iommu_device_init(struct kfd_dev *kfd)
  {
+#if IS_MODULE(CONFIG_AMD_IOMMU_V2)
+   WARN_ONCE(1, "iommu_v2 module is not usable by built-in KFD");
+#endif
return 0;
  }
  
@@ -73,6 +78,6 @@ static inline int kfd_iommu_add_perf_counters(struct kfd_topology_device *kdev)

return 0;
  }
  
-#endif /* defined(CONFIG_AMD_IOMMU_V2) */

+#endif /* IS_REACHABLE(CONFIG_AMD_IOMMU_V2) */
  
  #endif /* __KFD_IOMMU_H__ */

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: don't base trees on 5.12-rc1

[Daniel Vetter]

On Wed, Mar 10, 2021 at 8:11 PM Dave Airlie  wrote:
>
> On Wed, 10 Mar 2021 at 17:48, Maxime Ripard  wrote:
> >
> > Hi Dave,
> >
> > On Wed, Mar 10, 2021 at 09:50:29AM +1000, Dave Airlie wrote:
> > > I'm mostly sending this to the -misc maintainers because
> > > drm-misc-fixes is based on rc1 at present.
> > >
> > > This needs to be *rebased* not merged up to 5.12-rc2. Merging will
> > > still have the bad landmine commits in the bisect history. This is a
> > > very special case.
> >
> > I'm sorry, I'm not entirely sure I get this. -rc1 is still in the -rc2
> > history, so how would that change anything in the bisect history?
> >
>
> We can't get rid of the bad commit range, we can reduce the amount of
> times someone accidentally bisects into it, by not using it as a base
> commit for future changes.
>
> If in the future a bisect happens to want to test one of the patches
> in drm-misc-fixes that is based on rc1, it will land the user with an
> rc1 test kernel and could eat their swapfile/disk. We can avoid that
> problem by not using rc1 as a base for drm-misc-fixes.
>
> We can't avoid them bisecting into the broken commits between when
> this landed and was fixed, but rebasing trees can minimise the chances
> of this when bisecting other changesets.

Same for backmerge, backmerge -rc2, not -rc1. I think there's a
request for backmerge pending from Noralf anyway. Also for any topic
branch and all that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Drop relocation support on all new hardware (v3)

[Jason Ekstrand]

+Zbigniew for review

On Wed, Mar 10, 2021 at 3:50 PM Jason Ekstrand  wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do.  On the OpenGL side, Gen12+ is
> only supported by iris which never uses relocations.  The older i965
> driver in Mesa does use relocations but it only supports Intel hardware
> through Gen11 and has been deprecated for all hardware Gen9+.  The
> compute driver also never uses relocations.  This only leaves the media
> driver which is supposed to be switching to softpin going forward.
> Making softpin a requirement for all future hardware seems reasonable.
>
> Rejecting relocations starting with Gen12 has the benefit that we don't
> have to bother supporting it on platforms with local memory.  Given how
> much CPU touching of memory is required for relocations, not having to
> do so on platforms where not all memory is directly CPU-accessible
> carries significant advantages.
>
> v2 (Jason Ekstrand):
>  - Allow TGL-LP platforms as they've already shipped
>
> v3 (Jason Ekstrand):
>  - WARN_ON platforms with LMEM support in case the check is wrong
>
> Signed-off-by: Jason Ekstrand 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 99772f37bff60..b02dbd16bfa03 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1764,7 +1764,8 @@ eb_relocate_vma_slow(struct i915_execbuffer *eb, struct 
> eb_vma *ev)
> return err;
>  }
>
> -static int check_relocations(const struct drm_i915_gem_exec_object2 *entry)
> +static int check_relocations(const struct i915_execbuffer *eb,
> +const struct drm_i915_gem_exec_object2 *entry)
>  {
> const char __user *addr, *end;
> unsigned long size;
> @@ -1774,6 +1775,14 @@ static int check_relocations(const struct 
> drm_i915_gem_exec_object2 *entry)
> if (size == 0)
> return 0;
>
> +   /* Relocations are disallowed for all platforms after TGL-LP */
> +   if (INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +   return -EINVAL;
> +
> +   /* All discrete memory platforms are Gen12 or above */
> +   if (WARN_ON(HAS_LMEM(eb->i915)))
> +   return -EINVAL;
> +
> if (size > N_RELOC(ULONG_MAX))
> return -EINVAL;
>
> @@ -1807,7 +1816,7 @@ static int eb_copy_relocations(const struct 
> i915_execbuffer *eb)
> if (nreloc == 0)
> continue;
>
> -   err = check_relocations(&eb->exec[i]);
> +   err = check_relocations(eb, &eb->exec[i]);
> if (err)
> goto err;
>
> @@ -1880,7 +1889,7 @@ static int eb_prefault_relocations(const struct 
> i915_execbuffer *eb)
> for (i = 0; i < count; i++) {
> int err;
>
> -   err = check_relocations(&eb->exec[i]);
> +   err = check_relocations(eb, &eb->exec[i]);
> if (err)
> return err;
> }
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1

[Linus Walleij]

On Fri, Jan 15, 2021 at 11:44 PM Douglas Anderson  wrote:

> - ("drm/panel-simple: Don't wait longer for HPD...") new for v2.
> - ("drm/panel-simple: Retry if we timeout waiting for HPD") new for v2.

I couldn't find these patches in my inbox but my concern would
be that at some point panel-simple will turn from simple into
panel-rube-goldberg-machine.

Given that the talk with the manufacturer may result
in even more quirks... maybe this should just be a separate
panel driver?

(I expect pushback because I see how handy it is, but
I am the guy writing new panel drivers all the time rather than
using simple.)

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1

[Doug Anderson]

Hi,

On Wed, Mar 10, 2021 at 3:25 PM Linus Walleij  wrote:
>
> On Fri, Jan 15, 2021 at 11:44 PM Douglas Anderson  
> wrote:
>
> > - ("drm/panel-simple: Don't wait longer for HPD...") new for v2.
> > - ("drm/panel-simple: Retry if we timeout waiting for HPD") new for v2.
>
> I couldn't find these patches in my inbox

Doh! Sorry about that. I think get_maintainer tagged you only on the
patches that had the explicit "fixes" in them on something you were
involved in. I tend to rely on get_maintainer heavily unless I think
someone is particularly interested in the whole series. I will make
sure to CC you on the whole series if I post it again. In the meantime
the whole series is on lore:

https://lore.kernel.org/lkml/20210115224420.1635017-1-diand...@chromium.org/

> but my concern would
> be that at some point panel-simple will turn from simple into
> panel-rube-goldberg-machine.

Yes, it's definitely something to watch out for. I guess you're
commenting on the general number of changes I've made to simple-panel
in the last year or two? I guess my comment on those:

* Many of the changes I made were around HPD handling and supporting a
GPIO (and also supporting the "hpd absent delay"). The fact that we
use a GPIO for HPD is actually an attribute of our board design,
though, so if I had forked panel drivers for each of the panels that
needed it then it would have required copying the code lots of places
(or implementing some code sharing). I was specifically asked to do
the HPD handling code at the panel layer.

* The other big change I made recently was around allowing for
relative rather than absolute timings (instead of a fixed delay at a
given stage adding a constraint that enough time had passed since a
previous event). When I proposed that the feedback I got back was that
it was a good improvement for all panels and something that had been
on a TODO list for a while.

...so while it feels like I keep piling crap onto simple-panel, I
_think_ they've been good general improvements that many people will
be able to benefit from and I don't think they've uglified things
lots.

> Given that the talk with the manufacturer may result
> in even more quirks... maybe this should just be a separate
> panel driver?

I don't _think_ this will end up with more quirks. At least I sure
hope not. So far it seems like pure luck that I even noticed it
because only one other device in the whole batch produced had similar
problems. That leads me to believe that there could be other panels
with a similar need.

> (I expect pushback because I see how handy it is, but
> I am the guy writing new panel drivers all the time rather than
> using simple.)

I guess what I'd say in summary is:

* If you object to the retries in simple panel, I still hope the rest
of the series can land.

* If somehow this panel gets out into real users hands and we find
that the retries are necessary and people still don't want the retries
in simple panel, I can fork a special panel driver just for it then.

-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] fb_defio: Remove custom address_space_operations

[William Kucharski]

Looks good; my apologies for missing the leftover declaration of struct page in 
the same routine which you also found and removed this time around.

> On Mar 10, 2021, at 11:55 AM, Matthew Wilcox (Oracle)  
> wrote:
> 
> There's no need to give the page an address_space.  Leaving the
> page->mapping as NULL will cause the VM to handle set_page_dirty()
> the same way that it's handled now, and that was the only reason to
> set the address_space in the first place.
> 
> Signed-off-by: Matthew Wilcox (Oracle) 
> Reviewed-by: Christoph Hellwig 
> Reviewed-by: William Kucharski 
> ---
> v2: Delete local variable definitions
> drivers/video/fbdev/core/fb_defio.c | 35 -
> drivers/video/fbdev/core/fbmem.c|  4 
> include/linux/fb.h  |  3 ---
> 3 files changed, 42 deletions(-)
> 
> diff --git a/drivers/video/fbdev/core/fb_defio.c 
> b/drivers/video/fbdev/core/fb_defio.c
> index a591d291b231..b292887a2481 100644
> --- a/drivers/video/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -52,13 +52,6 @@ static vm_fault_t fb_deferred_io_fault(struct vm_fault 
> *vmf)
>   return VM_FAULT_SIGBUS;
> 
>   get_page(page);
> -
> - if (vmf->vma->vm_file)
> - page->mapping = vmf->vma->vm_file->f_mapping;
> - else
> - printk(KERN_ERR "no mapping available\n");
> -
> - BUG_ON(!page->mapping);
>   page->index = vmf->pgoff;
> 
>   vmf->page = page;
> @@ -151,17 +144,6 @@ static const struct vm_operations_struct 
> fb_deferred_io_vm_ops = {
>   .page_mkwrite   = fb_deferred_io_mkwrite,
> };
> 
> -static int fb_deferred_io_set_page_dirty(struct page *page)
> -{
> - if (!PageDirty(page))
> - SetPageDirty(page);
> - return 0;
> -}
> -
> -static const struct address_space_operations fb_deferred_io_aops = {
> - .set_page_dirty = fb_deferred_io_set_page_dirty,
> -};
> -
> int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
> {
>   vma->vm_ops = &fb_deferred_io_vm_ops;
> @@ -212,29 +194,12 @@ void fb_deferred_io_init(struct fb_info *info)
> }
> EXPORT_SYMBOL_GPL(fb_deferred_io_init);
> 
> -void fb_deferred_io_open(struct fb_info *info,
> -  struct inode *inode,
> -  struct file *file)
> -{
> - file->f_mapping->a_ops = &fb_deferred_io_aops;
> -}
> -EXPORT_SYMBOL_GPL(fb_deferred_io_open);
> -
> void fb_deferred_io_cleanup(struct fb_info *info)
> {
>   struct fb_deferred_io *fbdefio = info->fbdefio;
> - struct page *page;
> - int i;
> 
>   BUG_ON(!fbdefio);
>   cancel_delayed_work_sync(&info->deferred_work);
> -
> - /* clear out the mapping that we setup */
> - for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
> - page = fb_deferred_io_page(info, i);
> - page->mapping = NULL;
> - }
> -
>   mutex_destroy(&fbdefio->lock);
> }
> EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
> diff --git a/drivers/video/fbdev/core/fbmem.c 
> b/drivers/video/fbdev/core/fbmem.c
> index 06f5805de2de..372b52a2befa 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1415,10 +1415,6 @@ __releases(&info->lock)
>   if (res)
>   module_put(info->fbops->owner);
>   }
> -#ifdef CONFIG_FB_DEFERRED_IO
> - if (info->fbdefio)
> - fb_deferred_io_open(info, inode, file);
> -#endif
> out:
>   unlock_fb_info(info);
>   if (res)
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index ecfbcc0553a5..a8dccd23c249 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -659,9 +659,6 @@ static inline void __fb_pad_aligned_buffer(u8 *dst, u32 
> d_pitch,
> /* drivers/video/fb_defio.c */
> int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma);
> extern void fb_deferred_io_init(struct fb_info *info);
> -extern void fb_deferred_io_open(struct fb_info *info,
> - struct inode *inode,
> - struct file *file);
> extern void fb_deferred_io_cleanup(struct fb_info *info);
> extern int fb_deferred_io_fsync(struct file *file, loff_t start,
>   loff_t end, int datasync);
> -- 
> 2.30.0
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1

[Linus Walleij]

On Thu, Mar 11, 2021 at 12:47 AM Doug Anderson  wrote:

> I guess what I'd say in summary is:
>
> * If you object to the retries in simple panel, I still hope the rest
> of the series can land.
>
> * If somehow this panel gets out into real users hands and we find
> that the retries are necessary and people still don't want the retries
> in simple panel, I can fork a special panel driver just for it then.

I'm fine with the retries, if it is needed outside of the "simple" (hm)
panel driver then we can certainly factor it out as a helper or
library.

I looked at the patches at lore.
Reviewed-by: Linus Walleij 
I see also Stephen has reviewed some patches.

Tell me if you need me to also apply them to drm-misc.
(I guess yes?)

Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm/panel-simple: Patches for N116BCA-EA1

[Doug Anderson]

Hi,

On Wed, Mar 10, 2021 at 4:57 PM Linus Walleij  wrote:
>
> On Thu, Mar 11, 2021 at 12:47 AM Doug Anderson  wrote:
>
> > I guess what I'd say in summary is:
> >
> > * If you object to the retries in simple panel, I still hope the rest
> > of the series can land.
> >
> > * If somehow this panel gets out into real users hands and we find
> > that the retries are necessary and people still don't want the retries
> > in simple panel, I can fork a special panel driver just for it then.
>
> I'm fine with the retries, if it is needed outside of the "simple" (hm)
> panel driver then we can certainly factor it out as a helper or
> library.
>
> I looked at the patches at lore.
> Reviewed-by: Linus Walleij 
> I see also Stephen has reviewed some patches.
>
> Tell me if you need me to also apply them to drm-misc.
> (I guess yes?)

Yes please. I was giving Sam time to do it but I haven't heard from
him for a while. Right before you responded I poked Thierry to see if
he was available but if you're willing/able to do it then I'm sure it
would save him the trouble.

If you'd like me to re-post the patches (CCing you) I can. Please let me know.

If you happen to feel in an applying mood one other patch to
simple-panel I think is OK to land is at:

https://lore.kernel.org/r/20210222081716.1.I1a45aece5d2ac6a2e73bbec50da2086e43e0862b@changeid

-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] i915: Drop legacy execbuffer support

[Keith Packard]

Jason Ekstrand  writes:

> libdrm has supported the newer execbuffer2 ioctl and using it by default
> when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
> which landed Mar 2, 2010.  The i915 and i965 drivers in Mesa at the time
> both used libdrm and so did the Intel X11 back-end.  The SNA back-end
> for X11 has always used execbuffer2.

All execbuffer users in the past that I'm aware of used libdrm, which
now uses the execbuffer2 ioctl for this API. That means these
applications will remain ABI compatible through this change.

Acked-by: Keith Packard 

-- 
-keith


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/5] drm/ingenic: Add option to alloc cached GEM buffers

[Hillf Danton]

On Wed, 10 Mar 2021 19:01:01 + Paul Cercueil wrote:
>Le lun. 8 mars 2021 � 11:47, Hillf Danton  a �crit :
>> On Sun,  7 Mar 2021 20:28:35 +  Paul Cercueil wrote:
>>>  With the module parameter ingenic-drm.cached_gem_buffers, it is 
>>> possible
>>>  to specify that we want GEM buffers backed by non-coherent memory.
>>> 
>>>  This dramatically speeds up software rendering on Ingenic SoCs, 
>>> even for
>>>  tasks where write-combine memory should in theory be faster (e.g. 
>>> simple
>>>  blits).
>> 
>> Wondering if it is due to the tricks at [1].
>> 
>> If so, is dma_alloc_noncoherent() necessary in this patchset?
>
>You confuse non-contiguous with non-coherent, which are two different 
>things.

You misunderstood me. From [1] we know coherent caching is arch thing,
so your proposal is not mandatory on ARM IMHO - what baffles me is
noncoherent back memory can speed up device, coherent ot not, regardless
of arch. Can you point me to the reasons behind your speedup?

>
>Cheers,
>-Paul
>
>> Christoph can you give us a concise lesson on noncoherency covering 
>> at least
>> noncoherent device, noncoherent memory(used in this work), no coherent
>> caching(in [1]), their links to speedup, and the thumb rule to handle
>> noncoherency in workdays. It feels toe curling every time I see 
>> noncoherence
>> going downtown with speedup hand in hand.
>> 
>> [1] Subject: [PATCH 6/6] media: uvcvideo: Use dma_alloc_noncontiguos 
>> API
>> https://lore.kernel.org/lkml/20210301085236.947011-7-...@lst.de/#t
>> 
>>> 
>>>  Leave it disabled by default, since it is specific to one use-case
>>>  (software rendering).
>>> 
>>>  v2: Rework code to work with new DRM APIs regarding plane states
>>> 
>>>  Signed-off-by: Paul Cercueil 
>>>  ---
>>>   drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 49 
>>> ++-
>>>   drivers/gpu/drm/ingenic/ingenic-drm.h |  4 ++
>>>   drivers/gpu/drm/ingenic/ingenic-ipu.c | 14 ++-
>>>   3 files changed, 63 insertions(+), 4 deletions(-)
>>> 
>>>  diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
>>> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>>>  index d60e1eefc9d1..ba1ac0fcda74 100644
>>>  --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>>>  +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>>>  @@ -9,6 +9,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>>  +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>>  @@ -23,6 +24,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>>  +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>>  @@ -99,6 +101,11 @@ struct ingenic_drm {
>>> struct notifier_block clock_nb;
>>>   };
>>> 
>>>  +static bool ingenic_drm_cached_gem_buf;
>>>  +module_param_named(cached_gem_buffers, ingenic_drm_cached_gem_buf, 
>>> bool, 0400);
>>>  +MODULE_PARM_DESC(cached_gem_buffers,
>>>  +   "Enable fully cached GEM buffers [default=false]");
>>>  +
>>>   static bool ingenic_drm_writeable_reg(struct device *dev, unsigned 
>>> int reg)
>>>   {
>>> switch (reg) {
>>>  @@ -410,6 +417,8 @@ static int 
>>> ingenic_drm_plane_atomic_check(struct drm_plane *plane,
>>>  old_plane_state->fb->format->format != 
>>> new_plane_state->fb->format->format))
>>> crtc_state->mode_changed = true;
>>> 
>>>  +  drm_atomic_helper_check_plane_damage(state, new_plane_state);
>>>  +
>>> return 0;
>>>   }
>>> 
>>>  @@ -541,10 +550,20 @@ static void ingenic_drm_update_palette(struct 
>>> ingenic_drm *priv,
>>> }
>>>   }
>>> 
>>>  +void ingenic_drm_sync_data(struct device *dev,
>>>  + struct drm_plane_state *old_state,
>>>  + struct drm_plane_state *state)
>>>  +{
>>>  +  if (ingenic_drm_cached_gem_buf)
>>>  +  drm_gem_cma_sync_data(dev, old_state, state);
>>>  +}
>>>  +
>>>   static void ingenic_drm_plane_atomic_update(struct drm_plane 
>>> *plane,
>>> struct drm_atomic_state *state)
>>>   {
>>> struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
>>>  +  struct drm_plane_state *oldstate = 
>>> drm_atomic_get_old_plane_state(state,
>>>  +
>>> plane);
>>> struct drm_plane_state *newstate = 
>>> drm_atomic_get_new_plane_state(state,
>>>   
>>> plane);
>>> struct drm_crtc_state *crtc_state;
>>>  @@ -554,6 +573,8 @@ static void 
>>> ingenic_drm_plane_atomic_update(struct drm_plane *plane,
>>> u32 fourcc;
>>> 
>>> if (newstate && newstate->fb) {
>>>  +  ingenic_drm_sync_data(priv->dev, oldstate, newstate);
>>>  +
>>> crtc_state = newstate->crtc->state;
>>> 
>>> addr = drm_fb_cma_get_gem_addr(newstate->fb, newstate, 0);
>>>  @@ -743,6 +764,26 @@ static void ingenic_drm_disable_vblank(struct 
>>> drm_crtc *crtc)
>>> regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, 
>>> JZ_LCD_CTRL_EOF_IRQ, 0);
>>>   }
>>> 
>>>  +static struct drm_fr

[PATCH 2/2] drm/amdgpu: fix a few compiler warnings

[Oak Zeng]

1. make function mmhub_v1_7_setup_vm_pt_regs static
2. indent a if statement

Signed-off-by: Oak Zeng 
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
---
 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c | 4 ++--
 drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c 
b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
index 3b4193c..8fca72e 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v1_1.c
@@ -88,14 +88,14 @@ int gfxhub_v1_1_get_xgmi_info(struct amdgpu_device *adev)
adev->gmc.xgmi.num_physical_nodes = max_region + 1;
 
if (adev->gmc.xgmi.num_physical_nodes > max_num_physical_nodes)
-   return -EINVAL;
+   return -EINVAL;
 
adev->gmc.xgmi.physical_node_id =
REG_GET_FIELD(xgmi_lfb_cntl, MC_VM_XGMI_LFB_CNTL,
  PF_LFB_REGION);
 
if (adev->gmc.xgmi.physical_node_id > max_physical_node_id)
-   return -EINVAL;
+   return -EINVAL;
 
adev->gmc.xgmi.node_segment_size = seg_size;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c 
b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c
index ac74d66..29d7f50 100644
--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c
+++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_7.c
@@ -53,7 +53,7 @@ static u64 mmhub_v1_7_get_fb_location(struct amdgpu_device 
*adev)
return base;
 }
 
-void mmhub_v1_7_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t vmid,
+static void mmhub_v1_7_setup_vm_pt_regs(struct amdgpu_device *adev, uint32_t 
vmid,
uint64_t page_table_base)
 {
struct amdgpu_vmhub *hub = &adev->vmhub[AMDGPU_MMHUB_0];
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/amdgpu: fix compile error on architecture s390

[Oak Zeng]

ioremap_cache is not supported on some architecture
such as s390. Put the codes into a #ifdef to fix
some compile error reported by test robot.

Signed-off-by: Oak Zeng 
Reported-by: Kernel test robot 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 37751e7..1091585 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1817,7 +1817,7 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
 
/* Change the size here instead of the init above so only lpfn is 
affected */
amdgpu_ttm_set_buffer_funcs_status(adev, false);
-#ifdef CONFIG_64BIT
+#ifdef CONFIG_X86
if (adev->gmc.xgmi.connected_to_cpu)
adev->mman.aper_base_kaddr = ioremap_cache(adev->gmc.aper_base,
adev->gmc.visible_vram_size);
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: fix dma syncing for loops (v2)

[Dave Airlie]

From: Dave Airlie 

The index variable should only be increased in one place.

Noticed this while trying to track down another oops.

v2: use while loop.

Fixes: f295c8cfec83 ("drm/nouveau: fix dma syncing warning with debugging on.")
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 2375711877cf..fabb314a0b2f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -556,7 +556,8 @@ nouveau_bo_sync_for_device(struct nouveau_bo *nvbo)
if (nvbo->force_coherent)
return;
 
-   for (i = 0; i < ttm_dma->num_pages; ++i) {
+   i = 0;
+   while (i < ttm_dma->num_pages) {
struct page *p = ttm_dma->pages[i];
size_t num_pages = 1;
 
@@ -587,7 +588,8 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
if (nvbo->force_coherent)
return;
 
-   for (i = 0; i < ttm_dma->num_pages; ++i) {
+   i = 0;
+   while (i < ttm_dma->num_pages) {
struct page *p = ttm_dma->pages[i];
size_t num_pages = 1;
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 02/14] media: docs: Add some RGB bus formats for i.MX8qm/qxp pixel combiner

[Liu Ying]

Hi Laurent,

On Wed, 2021-03-10 at 15:24 +0200, Laurent Pinchart wrote:
> Hi Liu,
> 
> Thank you for the patch.

Thanks for your review.

> 
> On Wed, Mar 10, 2021 at 05:55:26PM +0800, Liu Ying wrote:
> > This patch adds documentations for RGB666_1X30_CPADLO, RGB888_1X30_CPADLO,
> > RGB666_1X36_CPADLO and RGB888_1X36_CPADLO bus formats used by i.MX8qm/qxp
> > pixel combiner.  The RGB pixels with padding low per component are
> > transmitted on a 30-bit input bus(10-bit per component) from a display
> > controller or a 36-bit output bus(12-bit per component) to a pixel link.
> > 
> > Reviewed-by: Robert Foss 
> > Signed-off-by: Liu Ying 
> > ---
> > v4->v5:
> > * Add Robert's R-b tag.
> > 
> > v3->v4:
> > * No change.
> > 
> > v2->v3:
> > * No change.
> > 
> > v1->v2:
> > * No change.
> > 
> >  .../userspace-api/media/v4l/subdev-formats.rst | 156 
> > +
> >  1 file changed, 156 insertions(+)
> > 
> > diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst 
> > b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > index 7f16cbe..201c16d 100644
> > --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > @@ -1488,6 +1488,80 @@ The following tables list existing packed RGB 
> > formats.
> >- b\ :sub:`2`
> >- b\ :sub:`1`
> >- b\ :sub:`0`
> > +* .. _MEDIA-BUS-FMT-RGB666-1X30-CPADLO:
> > +
> > +  - MEDIA_BUS_FMT_RGB666_1X30-CPADLO
> > +  - 0x101e
> > +  -
> > +  - 0
> > +  - 0
> 
> I count 32 bits here. Should these two 0 be replaced by spaces ? Same
> for MEDIA_BUS_FMT_RGB888_1X30-CPADLO.

Indeed, these two 0 should be spaces.  Will fix them in next version.

I see the in-tree MEDIA_BUS_FMT_RGB101010_1X30 has the same issue.
I can send another patch to fix it.

Regards,
Liu Ying

> 
> With this fixed,
> 
> Reviewed-by: Laurent Pinchart 
> 
> > +  - r\ :sub:`5`
> > +  - r\ :sub:`4`
> > +  - r\ :sub:`3`
> > +  - r\ :sub:`2`
> > +  - r\ :sub:`1`
> > +  - r\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - g\ :sub:`5`
> > +  - g\ :sub:`4`
> > +  - g\ :sub:`3`
> > +  - g\ :sub:`2`
> > +  - g\ :sub:`1`
> > +  - g\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - b\ :sub:`5`
> > +  - b\ :sub:`4`
> > +  - b\ :sub:`3`
> > +  - b\ :sub:`2`
> > +  - b\ :sub:`1`
> > +  - b\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +* .. _MEDIA-BUS-FMT-RGB888-1X30-CPADLO:
> > +
> > +  - MEDIA_BUS_FMT_RGB888_1X30-CPADLO
> > +  - 0x101f
> > +  -
> > +  - 0
> > +  - 0
> > +  - r\ :sub:`7`
> > +  - r\ :sub:`6`
> > +  - r\ :sub:`5`
> > +  - r\ :sub:`4`
> > +  - r\ :sub:`3`
> > +  - r\ :sub:`2`
> > +  - r\ :sub:`1`
> > +  - r\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - g\ :sub:`7`
> > +  - g\ :sub:`6`
> > +  - g\ :sub:`5`
> > +  - g\ :sub:`4`
> > +  - g\ :sub:`3`
> > +  - g\ :sub:`2`
> > +  - g\ :sub:`1`
> > +  - g\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - b\ :sub:`7`
> > +  - b\ :sub:`6`
> > +  - b\ :sub:`5`
> > +  - b\ :sub:`4`
> > +  - b\ :sub:`3`
> > +  - b\ :sub:`2`
> > +  - b\ :sub:`1`
> > +  - b\ :sub:`0`
> > +  - 0
> > +  - 0
> >  * .. _MEDIA-BUS-FMT-ARGB888-1X32:
> >  
> >- MEDIA_BUS_FMT_ARGB888_1X32
> > @@ -1665,6 +1739,88 @@ The following table list existing packed 36bit wide 
> > RGB formats.
> >- 2
> >- 1
> >- 0
> > +* .. _MEDIA-BUS-FMT-RGB666-1X36-CPADLO:
> > +
> > +  - MEDIA_BUS_FMT_RGB666_1X36_CPADLO
> > +  - 0x1020
> > +  -
> > +  - r\ :sub:`5`
> > +  - r\ :sub:`4`
> > +  - r\ :sub:`3`
> > +  - r\ :sub:`2`
> > +  - r\ :sub:`1`
> > +  - r\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - g\ :sub:`5`
> > +  - g\ :sub:`4`
> > +  - g\ :sub:`3`
> > +  - g\ :sub:`2`
> > +  - g\ :sub:`1`
> > +  - g\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - b\ :sub:`5`
> > +  - b\ :sub:`4`
> > +  - b\ :sub:`3`
> > +  - b\ :sub:`2`
> > +  - b\ :sub:`1`
> > +  - b\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +* .. _MEDIA-BUS-FMT-RGB888-1X36-CPADLO:
> > +
> > +  - MEDIA_BUS_FMT_RGB888_1X36_CPADLO
> > +  - 0x1021
> > +  -
> > +  - r\ :sub:`7`
> > +  - r\ :sub:`6`
> > +  - r\ :sub:`5`
> > +  - r\ :sub:`4`
> > +  - r\ :sub:`3`
> > +  - r\ :sub:`2`
> > +  - r\ :sub:`1`
> > +  - r\ :sub:`0`
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - 0
> > +  - g\ :sub:`7`
> > +  - g\ :sub:`6`
> > +  - g\ :sub:`5`
> > +  - g\ :sub:`4`

Re: [PATCH v2 0/5] Add option to mmap GEM buffers cached

[Thomas Zimmermann]

Hi

Am 10.03.21 um 20:02 schrieb Paul Cercueil:

Hi Thomas,

Le lun. 8 mars 2021 à 9:41, Thomas Zimmermann  a 
écrit :

Hi Paul,

having individual functions for each mode only makes sense if the 
decision is at compile time. But in patch 5, you're working around 
your earlier design by introducing in-driver helpers that select the 
correct CMA function.


In SHMEM helpers we have the flag map_wc in the GEM structure that 
selects the pages caching mode (wc vs uncached). I think CMA should 


Re-reading this, it should rather be WC and cached.

use this design as well. Have a map_noncoherent flag in the CMA GEM 
object and set it from the driver's implementation of gem_create_object.


Is that a new addition? That severely reduces the patchset size, which 
is perfect.


It was added a few months ago, around the time you send the first 
version of the patches at hand.


Originally, SHMEM uses write combining by default. And several drivers 
used default mapping flags instead (so usually cached). IIRC I 
streamlined everything and flipped the default. Most drivers can use 
cached mappings and only some require WC.


Recently there was also a patchset that added support for cached video 
RAM (or something like that). So at some point we could store these 
flags in drm_gem_object. For now, I'd just put a flag into 
drm_gem_cma_object.




I'll send a V3 then.


Great!

Best regards
Thomas



Cheers,
-Paul

And in the long run, we could try to consolidate all drivers/helpers 
mapping flags in struct drm_gem_object.


Best regards
Thomas

Am 07.03.21 um 21:28 schrieb Paul Cercueil:

Rework of my previous patchset which added support for GEM buffers
backed by non-coherent memory to the ingenic-drm driver.

Having GEM buffers backed by non-coherent memory is interesting in
the particular case where it is faster to render to a non-coherent
buffer then sync the data cache, than to render to a write-combine
buffer, and (by extension) much faster than using a shadow buffer.
This is true for instance on some Ingenic SoCs, where even simple
blits (e.g. memcpy) are about three times faster using this method.

For the record, the previous patchset was accepted for 5.10 then had
to be reverted, as it conflicted with some changes made to the DMA API.

This new patchset is pretty different as it adds the functionality to
the DRM core. The first three patches add variants to existing functions
but with the "non-coherent memory" twist, exported as GPL symbols. The
fourth patch adds a function to be used with the damage helpers.
Finally, the last patch adds support for non-coherent GEM buffers to the
ingenic-drm driver. The functionality is enabled through a module
parameter, and is disabled by default.

Cheers,
-Paul

Paul Cercueil (5):
   drm: Add and export function drm_gem_cma_create_noncoherent
   drm: Add and export function drm_gem_cma_dumb_create_noncoherent
   drm: Add and export function drm_gem_cma_mmap_noncoherent
   drm: Add and export function drm_gem_cma_sync_data
   drm/ingenic: Add option to alloc cached GEM buffers

  drivers/gpu/drm/drm_gem_cma_helper.c  | 223 +++---
  drivers/gpu/drm/ingenic/ingenic-drm-drv.c |  49 -
  drivers/gpu/drm/ingenic/ingenic-drm.h |   4 +
  drivers/gpu/drm/ingenic/ingenic-ipu.c |  14 +-
  include/drm/drm_gem_cma_helper.h  |  13 ++
  5 files changed, 273 insertions(+), 30 deletions(-)



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer






--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



OpenPGP_signature
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel