linux-next: Fixes tag needs some work in the drm tree

[Stephen Rothwell]

Hi all,

In commit

  289aabbf7bc8 ("drm/amd/display: Use vrr friendly pageflip throttling in DC.")

Fixes tag

  Fixes: bb47de736661 ("drm/amdgpu: Set FreeSync state using drm VRR

has these problem(s):

  - Please don't split Fixes tags over more than one line

-- 
Cheers,
Stephen Rothwell


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

[PATCH] [v3,2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel

[Jerry Han]

Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
panel.

Signed-off-by: Jerry Han 
Cc: Jitao Shi 
Cc: Nick Sanders 
Cc: YH Lin 
Cc: Rock wang 
---
 MAINTAINERS  |6 +
 drivers/gpu/drm/panel/Kconfig|   11 +
 drivers/gpu/drm/panel/Makefile   |1 +
 drivers/gpu/drm/panel/panel-boe-himax8279d.c | 1077 ++
 4 files changed, 1095 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-boe-himax8279d.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b2f710e..38e2881 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4636,6 +4636,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/ili9225.c
 F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 
+DRM DRIVER FOR BOE HIMAX8279D PANELS
+M: Jerry Han 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
+F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
+
 DRM DRIVER FOR INTEL I810 VIDEO CARDS
 S: Orphan / Obsolete
 F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30..e5dcfd1 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -186,4 +186,15 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
 
+config DRM_PANEL_BOE_HIMAX8279D
+   tristate "Boe Himax8279d panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Same type
+ TFT-LCD modules. The panel has a 1200x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9..8a36543 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_DRM_PANEL_SEIKO_43WVF1G) += panel-seiko-43wvf1g.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c 
b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
new file mode 100644
index 000..37dd258
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
@@ -0,0 +1,1077 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Huaqin Telecom Technology Co., Ltd
+ *
+ * Author: Jerry Han 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct panel_cmd {
+   size_t len;
+   const char *data;
+};
+
+#define _INIT_CMD(...) { \
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
+struct panel_desc {
+   const struct drm_display_mode *display_mode;
+   unsigned int bpc;
+   unsigned int width;
+   unsigned int height;
+
+   unsigned int delay_t1;
+   unsigned int reset_delay_t2;
+   unsigned int reset_delay_t3;
+   unsigned int reset_delay_t4;
+
+   unsigned long flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+   const struct panel_cmd *on_cmds;
+   const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+   const struct panel_desc *desc;
+
+   struct backlight_device *backlight;
+   struct gpio_desc *enable_gpio;
+   struct gpio_desc *pp33_gpio;
+   struct gpio_desc *pp18_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+void set_gpios(struct panel_info *pinfo, int enable)
+{
+   gpiod_set_value(pinfo->enable_gpio, enable);
+   gpiod_set_value(pinfo->pp33_gpio, enable);
+   gpiod_set_value(pinfo->pp18_gpio, enable);
+}
+
+static inline struct panel_info *to_panel_info(struct drm_panel *panel)
+{
+   return container_of(panel, struct panel_info, base);
+}
+
+static int panel_disable(struct drm_panel *panel)
+{
+   struct panel_info *pinfo = to_panel_info(panel);
+
+   backlight_disable(pinfo->backlight);
+
+   pinfo->enabled = false;
+
+   return 0;
+}
+
+static int panel_unprepare(struct drm_panel *panel)
+{
+   struct panel_info *pinfo = to_panel_info(panel);
+   int err;
+
+   if (!pinfo->prepared)
+   return 0;
+
+   /* send off code */
+   if (pinfo->desc->off_cmds) {
+   const struct panel_cmd *cmds = pinfo->desc->off_cmds;
+   unsigned int i;
+
+   for (i = 0; cmds[i].len != 0; i++) {
+

Re: The "udl" driver crashes the kernel.

[Wojtek Zabolotny]

Hi,

A few more details. In the current configuration, inspite of kernel warnings 
the system is working, and I was able to configure both monitors (LCD in my 
laptop and external LCD monitor connected to
UDL-165).

I have followed the procedure described in 
https://wiki.archlinux.org/index.php/DisplayLink#USB_2.0_DL-1x5,_DL-1x0_Devices

# xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x43 cap: 0xf, Source Output, Sink Output, Source Offload, Sink 
Offload crtcs: 2 outputs: 2 associated providers: 1 name:modesetting
Provider 1: id: 0x17a cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated 
providers: 1 name:modesetting
# xrandr --setprovideroutputsource 1 0

Afterwards I have configured screens in my Mate desktop using GUI.

However, the CPU occupancy is high and I get the following messages regarding 
the softmmu operation:

[  212.020300] swiotlb_tbl_map_single: 10 callbacks suppressed
[  212.020309] udl 4-1.2:1.0: swiotlb buffer is full (sz: 999424 bytes)
[  212.020315] udl 4-1.2:1.0: DMA: Out of SW-IOMMU space for 999424 bytes
[  278.355981] udl 4-1.2:1.0: swiotlb buffer is full (sz: 786432 bytes)
[  278.355988] udl 4-1.2:1.0: DMA: Out of SW-IOMMU space for 786432 bytes
[  298.657084] traps: mate-notificati[1944] trap int3 ip:7f1526cbdca5 
sp:7fffc1f65f00 error:0 in libglib-2.0.so.0.5800.3[7f1526c85000+7e000]
[  316.132315] udl 4-1.2:1.0: swiotlb buffer is full (sz: 1019904 bytes)
[  316.132319] udl 4-1.2:1.0: DMA: Out of SW-IOMMU space for 1019904 bytes

From time to time I also get the messages about the drm_get_object_put

Below are all the related messages. When I tried to disconnect the UDL-165 from 
USB socket, the whole system crashed immediately.

[  117.364046] usb 1-1.3: reset full-speed USB device number 3 using ehci-pci
[  134.269573] [drm] vendor descriptor length:22 data:22 5f 01 00 20 05 00 01 
03 04 02
[  134.436703] udl 4-1.2:1.0: fb1: udldrmfb frame buffer device
[  134.436735] [drm] Initialized udl 0.0.1 20120220 for 4-1.2:1.0 on minor 2
[  134.436742] [drm] Initialized udl on minor 2
[  134.436849] usbcore: registered new interface driver udl
[  136.095399] WARNING: CPU: 4 PID: 920 at drivers/gpu/drm/drm_gem.c:893 
drm_gem_object_put+0x33/0x40 [drm]
[  136.095403] Modules linked in: udl rfcomm ctr ccm cpufreq_userspace 
cpufreq_conservative cpufreq_powersave bnep nft_counter xt_owner xt_state 
xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
libcrc32c nft_compat nf_tables nfnetlink binfmt_misc uvcvideo arc4 iwldvm 
mac80211 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common 
btusb btrtl btbcm snd_hda_codec_realtek videodev
snd_hda_codec_generic btintel media bluetooth nvidia_drm(POE) iwlwifi i915 drbg 
nvidia_modeset(POE) ansi_cprng intel_rapl x86_pkg_temp_thermal intel_powerclamp 
ecdh_generic snd_hda_intel coretemp
snd_hda_codec kvm_intel snd_hda_core drm_kms_helper snd_hwdep snd_pcm_oss 
dell_laptop snd_mixer_oss dell_wmi dell_smbios dcdbas drm snd_pcm kvm cfg80211 
snd_timer snd joydev soundcore serio_raw
sparse_keymap pcspkr
[  136.095498]  mei_me mei i2c_algo_bit rfkill irqbypass iTCO_wdt 
iTCO_vendor_support wmi_bmof dell_smm_hwmon evdev dell_wmi_descriptor wmi sg 
intel_cstate intel_uncore pcc_cpufreq intel_rapl_perf
video dell_smo8800 button battery ac nvidia(POE) ipmi_devintf ipmi_msghandler 
parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
crc32c_generic fscrypto ecb algif_skcipher
af_alg dm_crypt dm_mod sr_mod cdrom sd_mod crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel xhci_pci 
xhci_hcd ehci_pci libata ehci_hcd aes_x86_64 realtek
crypto_simd usbcore cryptd psmouse scsi_mod glue_helper r8169 i2c_i801 libphy 
lpc_ich usb_common thermal
[  136.095604] CPU: 4 PID: 920 Comm: Xorg Tainted: P   OE 
4.19.0-2-amd64 #1 Debian 4.19.16-1
[  136.095607] Hardware name: Dell Inc.  Dell System Vostro 
3750/0VP036, BIOS A14 09/26/2012
[  136.095639] RIP: 0010:drm_gem_object_put+0x33/0x40 [drm]
[  136.095644] Code: 28 53 48 8b 47 08 48 8b 40 68 48 a9 f8 ff ff ff 74 18 48 
89 fb e8 ed 1f e6 dd 84 c0 75 02 5b c3 48 89 df 5b e9 0e fc ff ff c3 <0f> 0b eb 
e4 66 0f 1f 84 00 00 00 00 00 66 66 66 66
90 48 85 ff 74
[  136.095647] RSP: 0018:ba82c25f7d10 EFLAGS: 00010246
[  136.095652] RAX:  RBX: 97fd7f4eb000 RCX: 
[  136.095654] RDX:  RSI:  RDI: 97fd7f4eb000
[  136.095657] RBP: 97fda71cb820 R08: 97fd6893bd10 R09: 0100
[  136.095659] R10: 0014 R11:  R12: 
[  136.095662] R13: ba82c25f7dd0 R14: ba82c25f7dc8 R15: 97fd8de12e00
[  136.095666] FS:  7f57d6cfaa80() GS:97fdae30() 
knlGS:
[  136.095670] CS:  0010 DS:  ES:  CR0: 80050033
[  136.095672] CR2: 7f57bdeaa630 CR3: 000416a9e002 CR4: 000606e0
[  136.095675] Call Trace:
[  136.095695]  udl_gem_mmap+

[PATCH] [v3,2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel

[Jerry Han]

Support Boe Himax8279d 8.0" 1200x1920 TFT LCD panel, it is a MIPI DSI
panel.

Signed-off-by: Jerry Han 
Cc: Jitao Shi 
Cc: Nick Sanders 
Cc: YH Lin 
Cc: Rock wang 
---
 MAINTAINERS  |6 +
 drivers/gpu/drm/panel/Kconfig|   22 +
 drivers/gpu/drm/panel/Makefile   |1 +
 drivers/gpu/drm/panel/panel-boe-himax8279d.c | 1064 ++
 4 files changed, 1093 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-boe-himax8279d.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b2f710e..095fbbe 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4624,6 +4624,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 S: Maintained
 F: drivers/gpu/drm/bochs/
 
+DRM DRIVER FOR BOE HIMAX8279D PANELS
+M: Jerry Han 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-boe-himax8279d.c
+F: Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
+
 DRM DRIVER FOR FARADAY TVE200 TV ENCODER
 M: Linus Walleij 
 T: git git://anongit.freedesktop.org/drm/drm-misc
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 6020c30..d611424 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -17,6 +17,17 @@ config DRM_PANEL_ARM_VERSATILE
  reference designs. The panel is detected using special registers
  in the Versatile family syscon registers.
 
+config DRM_PANEL_BOE_HIMAX8279D
+   tristate "Boe Himax8279d panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Boe Himax8279d
+ TFT-LCD modules. The panel has a 1200x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 config DRM_PANEL_LVDS
tristate "Generic LVDS panel driver"
depends on OF
@@ -186,4 +197,15 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
 
+config DRM_PANEL_BOE_HIMAX8279D
+   tristate "Boe Himax8279d panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Same type
+ TFT-LCD modules. The panel has a 1200x1920 resolution and uses
+ 24 bit RGB per pixel. It provides a MIPI DSI interface to
+ the host and has a built-in LED backlight.
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 5ccaaa9..7285539 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
+obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
diff --git a/drivers/gpu/drm/panel/panel-boe-himax8279d.c 
b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
new file mode 100644
index 000..9af382c
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-himax8279d.c
@@ -0,0 +1,1064 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Huaqin Telecom Technology Co., Ltd
+ *
+ * Author: Jerry Han 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct panel_cmd {
+   size_t len;
+   const char *data;
+};
+
+#define _INIT_CMD(...) { \
+   .len = sizeof((char[]){__VA_ARGS__}), \
+   .data = (char[]){__VA_ARGS__} }
+
+struct panel_desc {
+   const struct drm_display_mode *display_mode;
+   unsigned int bpc;
+   unsigned int width_mm;
+   unsigned int height_mm;
+
+   unsigned int delay_t1;
+   unsigned int reset_delay_t2;
+   unsigned int reset_delay_t3;
+   unsigned int reset_delay_t4;
+
+   unsigned long mode_flags;
+   enum mipi_dsi_pixel_format format;
+   unsigned int lanes;
+   const struct panel_cmd *on_cmds;
+   const struct panel_cmd *off_cmds;
+};
+
+struct panel_info {
+   struct drm_panel base;
+   struct mipi_dsi_device *link;
+   const struct panel_desc *desc;
+
+   struct backlight_device *backlight;
+   struct gpio_desc *enable_gpio;
+   struct gpio_desc *pp33_gpio;
+   struct gpio_desc *pp18_gpio;
+
+   bool prepared;
+   bool enabled;
+};
+
+static inline struct panel_info *to_panel_info(struct drm_panel *panel)
+{
+   return container_of(panel, struct panel_info, base);
+}
+
+void set_gpios(struct panel_info *pinfo, int enable)
+{
+   gpiod_set_value(pinfo->enable_gpio, enable);
+   gpiod_set_value(pinfo->pp33_gpio, e

Re: The "udl" driver crashes the kernel.

[Wojtek Zabolotny]

On 26.11.2018 00:07, Pavel Machek wrote:
> On Sun 2018-11-25 16:58:59, wzabo...@elektron.elka.pw.edu.pl wrote:
>> When I connect my Displaylink DL-165 adapter to my Debian/testing
>> machine, the "udl" driver is loaded and the following error messages
>> appears in kernel logs:
> 4.18 kernel. Might be worth testing latest stable, and latest
> mainline...
>
> Is there version that worked for you?
>
> I added udl maintainers to the Cc list.
>
> Best regards,

I have repeated the tests with my current Debian/testing setup (kernel 
4.19.16), and still get warnings from kernel after loading the udl module:

[ 1208.605542] [drm] vendor descriptor length:22 data:22 5f 01 00 20 05 00 01 
03 04 02
[ 1208.706718] udl 4-1.2:1.0: fb1: udldrmfb frame buffer device
[ 1208.706746] [drm] Initialized udl 0.0.1 20120220 for 4-1.2:1.0 on minor 2
[ 1208.706753] [drm] Initialized udl on minor 2
[ 1208.706876] usbcore: registered new interface driver udl
[ 1210.003149] WARNING: CPU: 0 PID: 993 at drivers/gpu/drm/drm_gem.c:893 
drm_gem_object_put+0x33/0x40 [drm]
[ 1210.003153] Modules linked in: udl evdi(OE) rfcomm ctr ccm bnep 
cpufreq_userspace cpufreq_conservative cpufreq_powersave nft_counter xt_owner 
xt_state xt_conntrack nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 libcrc32c nft_compat nf_tables nfnetlink binfmt_misc arc4 iwldvm 
mac80211 uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 iwlwifi 
videobuf2_common nvidia_drm(POE)
nvidia_modeset(POE) videodev intel_rapl media x86_pkg_temp_thermal 
intel_powerclamp btusb snd_hda_codec_realtek snd_hda_codec_generic btrtl btbcm 
btintel bluetooth snd_hda_intel i915 snd_hda_codec
snd_hda_core drbg ansi_cprng snd_hwdep snd_pcm_oss snd_mixer_oss coretemp 
kvm_intel snd_pcm ecdh_generic kvm snd_timer snd joydev serio_raw soundcore 
drm_kms_helper cfg80211 irqbypass dell_wmi
sparse_keymap pcspkr drm dell_laptop
[ 1210.003247]  dell_smbios mei_me rfkill i2c_algo_bit dcdbas intel_cstate 
iTCO_wdt mei iTCO_vendor_support intel_uncore dell_smm_hwmon evdev nvidia(POE) 
pcc_cpufreq intel_rapl_perf sg
dell_wmi_descriptor wmi_bmof wmi video ac button battery dell_smo8800 
ipmi_devintf ipmi_msghandler parport_pc ppdev lp parport ip_tables x_tables 
autofs4 ext4 crc16 mbcache jbd2 crc32c_generic
fscrypto ecb algif_skcipher af_alg dm_crypt dm_mod sr_mod cdrom sd_mod 
ums_realtek uas usb_storage crct10dif_pclmul crc32_pclmul crc32c_intel 
ghash_clmulni_intel pcbc ahci xhci_pci libahci xhci_hcd
ehci_pci libata ehci_hcd realtek aesni_intel aes_x86_64 crypto_simd cryptd 
usbcore psmouse glue_helper scsi_mod r8169 i2c_i801 libphy lpc_ich usb_common 
thermal [last unloaded: udlfb]
[ 1210.003358] CPU: 0 PID: 993 Comm: Xorg Tainted: P   OE 
4.19.0-2-amd64 #1 Debian 4.19.16-1
[ 1210.003360] Hardware name: Dell Inc.  Dell System Vostro 
3750/0VP036, BIOS A14 09/26/2012
[ 1210.003393] RIP: 0010:drm_gem_object_put+0x33/0x40 [drm]
[ 1210.003397] Code: 28 53 48 8b 47 08 48 8b 40 68 48 a9 f8 ff ff ff 74 18 48 
89 fb e8 ed 7f 05 f8 84 c0 75 02 5b c3 48 89 df 5b e9 0e fc ff ff c3 <0f> 0b eb 
e4 66 0f 1f 84 00 00 00 00 00 66 66 66 66
90 48 85 ff 74
[ 1210.003400] RSP: 0018:aa4cc23b3d10 EFLAGS: 00010246
[ 1210.003405] RAX:  RBX: 9e749ad90800 RCX: 
[ 1210.003408] RDX:  RSI:  RDI: 9e749ad90800
[ 1210.003411] RBP: 9e7496cbf020 R08: 9e74a720c910 R09: 0100
[ 1210.003413] R10: 0014 R11:  R12: 
[ 1210.003416] R13: aa4cc23b3dd0 R14: aa4cc23b3dc8 R15: 9e74a2695d00
[ 1210.003420] FS:  7ff1907cca80() GS:9e74ae20() 
knlGS:
[ 1210.003423] CS:  0010 DS:  ES:  CR0: 80050033
[ 1210.003426] CR2: 7ff18c785278 CR3: 0004290f6002 CR4: 000606f0
[ 1210.003429] Call Trace:
[ 1210.003446]  udl_gem_mmap+0x64/0xa0 [udl]
[ 1210.003484]  ? drm_mode_create_dumb_ioctl+0x10/0x10 [drm]
[ 1210.003515]  drm_ioctl_kernel+0xa1/0xf0 [drm]
[ 1210.003549]  drm_ioctl+0x206/0x3a0 [drm]
[ 1210.003584]  ? drm_mode_create_dumb_ioctl+0x10/0x10 [drm]
[ 1210.003592]  ? datagram_poll+0x25/0xf0
[ 1210.003599]  ? sock_poll+0x83/0xb0
[ 1210.003605]  ? ep_item_poll.isra.16+0x40/0xc0
[ 1210.003609]  ? sock_poll+0x83/0xb0
[ 1210.003616]  do_vfs_ioctl+0xa4/0x630
[ 1210.003621]  ? __x64_sys_epoll_ctl+0xe7/0x550
[ 1210.003626]  ksys_ioctl+0x60/0x90
[ 1210.003632]  __x64_sys_ioctl+0x16/0x20
[ 1210.003639]  do_syscall_64+0x53/0x100
[ 1210.003645]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1210.003650] RIP: 0033:0x7ff190efd757
[ 1210.003654] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7
d8 64 89 01 48
[ 1210.003657] RSP: 002b:7ffd9dcaca98 EFLAGS: 3246 ORIG_RAX: 
0010
[ 1210.003662] RAX: ffda RBX:  RCX: 7ff190efd757
[ 1210.003664] RDX: 000

Re: The "udl" driver crashes the kernel.

[Wojtek Zabolotny]

Hi,

It appeared that the crash was not immediate, and the messages got saved into 
/var/log/messages.
Below is full set of messages generated after disconnection of UDL-165.

I hope that they may help to isolate the problem.
With best regards,
Wojtek

Mar  3 21:39:35 wzdell kernel: [ 1270.474832] usb 4-1.2: USB disconnect, device 
number 3
Mar  3 21:39:35 wzdell kernel: [ 1270.475503] WARNING: CPU: 6 PID: 72 at 
drivers/gpu/drm/drm_mode_config.c:444 drm_mode_config_cleanup+0x288/0x2e0 [drm]
Mar  3 21:39:35 wzdell kernel: [ 1270.475505] Modules linked in: udl rfcomm ctr 
ccm cpufreq_userspace cpufreq_conservative cpufreq_powersave bnep nft_counter 
xt_owner xt_state xt_conntrack
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c nft_compat nf_tables 
nfnetlink binfmt_misc uvcvideo arc4 iwldvm mac80211 videobuf2_vmalloc 
videobuf2_memops videobuf2_v4l2 videobuf2_common btusb
btrtl btbcm snd_hda_codec_realtek videodev snd_hda_codec_generic btintel media 
bluetooth nvidia_drm(POE) iwlwifi i915 drbg nvidia_modeset(POE) ansi_cprng 
intel_rapl x86_pkg_temp_thermal
intel_powerclamp ecdh_generic snd_hda_intel coretemp snd_hda_codec kvm_intel 
snd_hda_core drm_kms_helper snd_hwdep snd_pcm_oss dell_laptop snd_mixer_oss 
dell_wmi dell_smbios dcdbas drm snd_pcm kvm
cfg80211 snd_timer snd joydev soundcore serio_raw sparse_keymap pcspkr
Mar  3 21:39:35 wzdell kernel: [ 1270.475561]  mei_me mei i2c_algo_bit rfkill 
irqbypass iTCO_wdt iTCO_vendor_support wmi_bmof dell_smm_hwmon evdev 
dell_wmi_descriptor wmi sg intel_cstate intel_uncore
pcc_cpufreq intel_rapl_perf video dell_smo8800 button battery ac nvidia(POE) 
ipmi_devintf ipmi_msghandler parport_pc ppdev lp parport ip_tables x_tables 
autofs4 ext4 crc16 mbcache jbd2 crc32c_generic
fscrypto ecb algif_skcipher af_alg dm_crypt dm_mod sr_mod cdrom sd_mod 
crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci 
libahci aesni_intel xhci_pci xhci_hcd ehci_pci libata
ehci_hcd aes_x86_64 realtek crypto_simd usbcore cryptd psmouse scsi_mod 
glue_helper r8169 i2c_i801 libphy lpc_ich usb_common thermal
Mar  3 21:39:35 wzdell kernel: [ 1270.475626] CPU: 6 PID: 72 Comm: kworker/6:1 
Tainted: P    W  OE 4.19.0-2-amd64 #1 Debian 4.19.16-1
Mar  3 21:39:35 wzdell kernel: [ 1270.475627] Hardware name: Dell Inc.  
Dell System Vostro 3750/0VP036, BIOS A14 09/26/2012
Mar  3 21:39:35 wzdell kernel: [ 1270.475645] Workqueue: usb_hub_wq hub_event 
[usbcore]
Mar  3 21:39:35 wzdell kernel: [ 1270.475666] RIP: 
0010:drm_mode_config_cleanup+0x288/0x2e0 [drm]
Mar  3 21:39:35 wzdell kernel: [ 1270.475669] Code: 17 de 48 8b 45 00 48 39 c5 
75 62 48 8b 44 24 30 65 48 33 04 25 28 00 00 00 75 56 48 83 c4 38 5b 5d 41 5c 
41 5d 41 5e 41 5f c3 <0f> 0b 48 89 e6 48 89
ef 48 c7 c3 20 de b9 c1 e8 04 8c ff ff eb 0c
Mar  3 21:39:35 wzdell kernel: [ 1270.475671] RSP: 0018:ba82c1df7ba8 
EFLAGS: 00010216
Mar  3 21:39:35 wzdell kernel: [ 1270.475673] RAX: 97fda71c8818 RBX: 
97fda71cab68 RCX: 
Mar  3 21:39:35 wzdell kernel: [ 1270.475675] RDX: 97fda71cab30 RSI: 
 RDI: 97fda71cab48
Mar  3 21:39:35 wzdell kernel: [ 1270.475676] RBP: 97fda71ca800 R08: 
 R09: c1b7d800
Mar  3 21:39:35 wzdell kernel: [ 1270.475678] R10: 97fd817d6080 R11: 
0001 R12: 97fda71cab70
Mar  3 21:39:35 wzdell kernel: [ 1270.475679] R13: 97fdabb91000 R14: 
97fdabb910a0 R15: ffed
Mar  3 21:39:35 wzdell kernel: [ 1270.475682] FS:  () 
GS:97fdae38() knlGS:
Mar  3 21:39:35 wzdell kernel: [ 1270.475683] CS:  0010 DS:  ES:  CR0: 
80050033
Mar  3 21:39:35 wzdell kernel: [ 1270.475685] CR2: 559468f29b7c CR3: 
0001c120a003 CR4: 000606e0
Mar  3 21:39:35 wzdell kernel: [ 1270.475686] Call Trace:
Mar  3 21:39:35 wzdell kernel: [ 1270.475697]  udl_driver_unload+0x2a/0x40 [udl]
Mar  3 21:39:35 wzdell kernel: [ 1270.475717]  drm_dev_unregister+0x4b/0xe0 
[drm]
Mar  3 21:39:35 wzdell kernel: [ 1270.475737]  drm_dev_unplug+0x21/0x60 [drm]
Mar  3 21:39:35 wzdell kernel: [ 1270.475751]  usb_unbind_interface+0x79/0x290 
[usbcore]
Mar  3 21:39:35 wzdell kernel: [ 1270.475758]  
device_release_driver_internal+0x1af/0x270
Mar  3 21:39:35 wzdell kernel: [ 1270.475763]  bus_remove_device+0xe5/0x150
Mar  3 21:39:35 wzdell kernel: [ 1270.475767]  device_del+0x136/0x350
Mar  3 21:39:35 wzdell kernel: [ 1270.475780]  usb_disable_device+0x93/0x250 
[usbcore]
Mar  3 21:39:35 wzdell kernel: [ 1270.475793]  usb_disconnect+0xc3/0x270 
[usbcore]
Mar  3 21:39:35 wzdell kernel: [ 1270.475806]  hub_event+0xc80/0x15a0 [usbcore]
Mar  3 21:39:35 wzdell kernel: [ 1270.475812]  process_one_work+0x1a7/0x3a0
Mar  3 21:39:35 wzdell kernel: [ 1270.475816]  worker_thread+0x30/0x390
Mar  3 21:39:35 wzdell kernel: [ 1270.475820]  ? 
pwq_unbound_release_workfn+0xd0/0xd0
Mar  3 21:39:35 wzdell kernel: [ 1270.475822]  kthread+0x112/0x130
Mar  3 21:39:35 wzdell kernel: 

[PATCH] [v3, 1/2] dt-bindings: panel: Add Boe Himax8279d is 1200x1920, 4-lane MIPI-DSI LCD panel

[Jerry Han]

The Boe Himax8279d is a 8.0" panel with a 1200x1920 resolution and
connected to DSI using four lanes.

Signed-off-by: Jerry Han 
Cc: Jitao Shi 
Cc: Nick Sanders 
Cc: YH Lin 
Cc: Rock wang 
---
 .../bindings/display/panel/boe,himax8279d.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt

diff --git a/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt 
b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
new file mode 100644
index 000..3caea21
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,himax8279d.txt
@@ -0,0 +1,24 @@
+Boe Himax8279d 1200x1920 TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,himax8279d8p" and one of: "boe,himax8279d10p"
+- reg: DSI virtual channel of the peripheral
+- enable-gpios: panel enable gpio
+- pp33-gpios: a GPIO phandle for the 3.3v pin that provides the supply voltage
+- pp18-gpios: a GPIO phandle for the 1.8v pin that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+
+   &mipi_dsi {
+   panel {
+   compatible = "boe,himax8279d8p", "boe,himax8279d10p";
+   reg = <0>;
+   backlight = <&backlight>;
+   enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+   pp33-gpios = <&gpio 35 GPIO_ACTIVE_HIGH>;
+   pp18-gpios = <&gpio 36 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
1.9.1

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

Re: [PATCH] virtgpu: Update kernel header

[Robert Foss]

Hey Gurchetan,

Thanks for sending this in!

Reviewed-by: Robert Foss 

On 2/28/19 1:52 AM, Gurchetan Singh wrote:

Generated using make headers_install.

This brings in the in/out fence support for explicit
synchronization.

v2: don't use experimental kernel branch

Signed-off-by: Gurchetan Singh 
---
  include/drm/virtgpu_drm.h | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/include/drm/virtgpu_drm.h b/include/drm/virtgpu_drm.h
index 9a781f06..f06a789f 100644
--- a/include/drm/virtgpu_drm.h
+++ b/include/drm/virtgpu_drm.h
@@ -47,6 +47,13 @@ extern "C" {
  #define DRM_VIRTGPU_WAIT 0x08
  #define DRM_VIRTGPU_GET_CAPS  0x09
  
+#define VIRTGPU_EXECBUF_FENCE_FD_IN	0x01

+#define VIRTGPU_EXECBUF_FENCE_FD_OUT   0x02
+#define VIRTGPU_EXECBUF_FLAGS  (\
+   VIRTGPU_EXECBUF_FENCE_FD_IN |\
+   VIRTGPU_EXECBUF_FENCE_FD_OUT |\
+   0)
+
  struct drm_virtgpu_map {
__u64 offset; /* use for mmap system call */
__u32 handle;
@@ -54,12 +61,12 @@ struct drm_virtgpu_map {
  };
  
  struct drm_virtgpu_execbuffer {

-   __u32   flags;  /* for future use */
+   __u32 flags;
__u32 size;
__u64 command; /* void* */
__u64 bo_handles;
__u32 num_bo_handles;
-   __u32 pad;
+   __s32 fence_fd; /* in/out fence fd (see 
VIRTGPU_EXECBUF_FENCE_FD_IN/OUT) */
  };
  
  #define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */

@@ -137,7 +144,7 @@ struct drm_virtgpu_get_caps {
DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_MAP, struct drm_virtgpu_map)
  
  #define DRM_IOCTL_VIRTGPU_EXECBUFFER \

-   DRM_IOW(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
+   DRM_IOWR(DRM_COMMAND_BASE + DRM_VIRTGPU_EXECBUFFER,\
struct drm_virtgpu_execbuffer)
  
  #define DRM_IOCTL_VIRTGPU_GETPARAM \



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

Re: [PATCH v2] drm/bridge: sil_sii8620: make remote control optional.

[Life is hard, and then you die]

On Thu, Jan 24, 2019 at 05:33:55PM -0800, Ronald Tschalär wrote:
> commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
> of RC_CORE) changed the driver to select both RC_CORE and INPUT.
> However, this causes problems with other drivers, in particular an input
> driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate
> commit):
> 
>   drivers/clk/Kconfig:9:error: recursive dependency detected!
>   drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by 
> MFD_INTEL_LPSS
>   drivers/mfd/Kconfig:566:  symbol MFD_INTEL_LPSS is selected by 
> MFD_INTEL_LPSS_PCI
>   drivers/mfd/Kconfig:580:  symbol MFD_INTEL_LPSS_PCI is implied by 
> KEYBOARD_APPLESPI
>   drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on 
> INPUT
>   drivers/input/Kconfig:8:  symbol INPUT is selected by DRM_SIL_SII8620
>   drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on 
> DRM_BRIDGE
>   drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by 
> DRM_PL111
>   drivers/gpu/drm/pl111/Kconfig:1:  symbol DRM_PL111 depends on COMMON_CLK
> 
> According to the docs and general consensus, select should only be used
> for non user-visible symbols, but both RC_CORE and INPUT are
> user-visible. Furthermore almost all other references to INPUT
> throughout the kernel config are depends, not selects. For this reason
> the first part of this change reverts commit d6abe6df706c.
> 
> In order to address the original reason for commit d6abe6df706c, namely
> that not all boards use the remote controller functionality and hence
> should not need have to deal with RC_CORE, the second part of this
> change now makes the remote control support in the driver optional and
> contingent on RC_CORE being defined. And with this the hard dependency
> on INPUT also goes away as that is only needed if RC_CORE is defined
> (which in turn already depends on INPUT).
> 
> CC: Inki Dae 
> CC: Andrzej Hajda 
> CC: Laurent Pinchart 
> CC: Dmitry Torokhov 
> Signed-off-by: Ronald Tschalär 
> ---
> Resending this, as I somehow managed to forget to cc dri-devel.
> Apologies for the duplication.
> 
> Changes in v2:
>  - completely remove dependencies on both RC_CORE and INPUT in Kconfig,
>  - make remote control functionality in driver contingent on RC_CORE
>being defined
> 
>  drivers/gpu/drm/bridge/Kconfig   |  2 --
>  drivers/gpu/drm/bridge/sil-sii8620.c | 17 +
>  2 files changed, 17 insertions(+), 2 deletions(-)
[snip]

Is there anything I can do to help get this reviewed and moved forward?


  Cheers,

  Ronald

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

RE: [PATCH] drm/amd/powerplay: fix memdup.cocci warnings

[Huang, Ray]

>  -Original Message-
> From: Julia Lawall [mailto:julia.law...@lip6.fr]
> Sent: Saturday, March 02, 2019 2:51 PM
> To: Gao, Likun 
> Cc: Deucher, Alexander ; Wang, Kevin(Yang)
> ; Quan, Evan ; Koenig,
> Christian ; David Airlie ;
> Daniel Vetter ; Huang, Ray ; amd-
> g...@lists.freedesktop.org; kbuild test robot ; dri-
> de...@lists.freedesktop.org; kbuild-...@01.org
> Subject: [PATCH] drm/amd/powerplay: fix memdup.cocci warnings
> 
> From: kbuild test robot 
> 
> Simplify the code a bit by using kmemdup instead of kzalloc and memcpy.
> 
> Generated by: scripts/coccinelle/api/memdup.cocci
> 
> Fixes: 76760fe3c00d ("drm/amd/powerplay: add function to store overdrive
> information for smu11")
> CC: Likun Gao 
> Signed-off-by: kbuild test robot 
> Signed-off-by: Julia Lawall 

Acked-by: Huang Rui 

> ---
> 
> tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
> head:   25752e1fc83e9f983b11d680fc7bfc129b4eaae6
> commit: 76760fe3c00d04f25cc1a6115294310d4effeb77 [161/226]
> drm/amd/powerplay: add function to store overdrive information for smu11
> :: branch date: 6 hours ago
> :: commit date: 6 hours ago
> 
>  vega20_ppt.c |   24 +---
>  1 file changed, 9 insertions(+), 15 deletions(-)
> 
> --- a/drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c
> @@ -173,14 +173,12 @@ static int vega20_setup_od8_information(
>   if (table_context->od_feature_capabilities)
>   return -EINVAL;
> 
> - table_context->od_feature_capabilities =
> kzalloc(od_feature_array_size, GFP_KERNEL);
> + table_context->od_feature_capabilities =
> kmemdup(&powerplay_table->OverDrive8Table.ODFeatureCapabilities,
> +
> od_feature_array_size,
> +
> GFP_KERNEL);
>   if (!table_context->od_feature_capabilities)
>   return -ENOMEM;
> 
> - memcpy(table_context->od_feature_capabilities,
> -&powerplay_table-
> >OverDrive8Table.ODFeatureCapabilities,
> -od_feature_array_size);
> -
>   /* Setup correct ODSettingCount, and store ODSettingArray
> from
>* powerplay table to od_settings_max and od_setting_min
> */
>   od_setting_count =
> @@ -194,7 +192,9 @@ static int vega20_setup_od8_information(
>   if (table_context->od_settings_max)
>   return -EINVAL;
> 
> - table_context->od_settings_max =
> kzalloc(od_setting_array_size, GFP_KERNEL);
> + table_context->od_settings_max =
> kmemdup(&powerplay_table->OverDrive8Table.ODSettingsMax,
> +
> od_setting_array_size,
> +  GFP_KERNEL);
> 
>   if (!table_context->od_settings_max) {
>   kfree(table_context->od_feature_capabilities);
> @@ -202,14 +202,12 @@ static int vega20_setup_od8_information(
>   return -ENOMEM;
>   }
> 
> - memcpy(table_context->od_settings_max,
> -&powerplay_table->OverDrive8Table.ODSettingsMax,
> -od_setting_array_size);
> -
>   if (table_context->od_settings_min)
>   return -EINVAL;
> 
> - table_context->od_settings_min =
> kzalloc(od_setting_array_size, GFP_KERNEL);
> + table_context->od_settings_min =
> kmemdup(&powerplay_table->OverDrive8Table.ODSettingsMin,
> +
> od_setting_array_size,
> +  GFP_KERNEL);
> 
>   if (!table_context->od_settings_min) {
>   kfree(table_context->od_feature_capabilities);
> @@ -218,10 +216,6 @@ static int vega20_setup_od8_information(
>   table_context->od_settings_max = NULL;
>   return -ENOMEM;
>   }
> -
> - memcpy(table_context->od_settings_min,
> -&powerplay_table->OverDrive8Table.ODSettingsMin,
> -od_setting_array_size);
>   }
> 
>   return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/bridge: sii902x: Select I2C_MUX

[Andrzej Hajda]

On 27.02.2019 22:54, Jyri Sarha wrote:
> "drm/bridge/sii902x: Fix EDID readback"-commit added a dependency to
> I2C_MUX, but not indicate it in the Kconfig entry. Fix it by selecting
> I2C_MUX for DRM_SII902X config option.
>
> Fixes: 88664675239 ("drm/bridge/sii902x: Fix EDID readback")
> Signed-off-by: Jyri Sarha 
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej
> ---
>  drivers/gpu/drm/bridge/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index fb0b37918382..a6f6ff8f06b3 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -95,6 +95,7 @@ config DRM_SII902X
>   depends on OF
>   select DRM_KMS_HELPER
>   select REGMAP_I2C
> + select I2C_MUX
>   ---help---
> Silicon Image sii902x bridge chip driver.
>  


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

[Bug 109808] ROCm OpenCL segfaults on drm-next-5.1-wip

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109808

--- Comment #3 from Michael Eagle  ---
Hi Philip,
I was wondering. Is it possible so that the message would be either more
descriptive so that user is informed about this or the kernel config to be
modified to automatically satisfy dependencies?

On Sun, Mar 3, 2019 at 10:36 PM  wrote:

> bmil...@gmail.com changed bug 109808
> 
> What Removed Added
> Resolution --- NOTABUG
> Status NEW RESOLVED
>
> *Comment # 2  on
> bug 109808  from
> bmil...@gmail.com  *
>
> Thanks for the answer, it was indeed a previous outdated config. Tested with
> CONFIG_ZONE_DEVICE=y and issue is gone, closing this.
>
> --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Bug 109808] ROCm OpenCL segfaults on drm-next-5.1-wip

[Mihai]

Hi Philip,
I was wondering. Is it possible so that the message would be either more
descriptive so that user is informed about this or the kernel config to be
modified to automatically satisfy dependencies?

On Sun, Mar 3, 2019 at 10:36 PM  wrote:

> bmil...@gmail.com changed bug 109808
> 
> What Removed Added
> Resolution --- NOTABUG
> Status NEW RESOLVED
>
> *Comment # 2  on
> bug 109808  from
> bmil...@gmail.com  *
>
> Thanks for the answer, it was indeed a previous outdated config. Tested with
> CONFIG_ZONE_DEVICE=y and issue is gone, closing this.
>
> --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>
> ___
> 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 5/5] drm/bridge: sii902x: Implement HDMI audio support

[Andrzej Hajda]

On 27.02.2019 22:54, Jyri Sarha wrote:
> Implement HDMI audio support by using ASoC HDMI codec. The commit
> implements the necessary callbacks and configuration for the HDMI
> codec and registers a virtual platform device for the codec to attach.
>
> Signed-off-by: Jyri Sarha 
> ---
>  .../bindings/display/bridge/sii902x.txt   |  36 +-
>  drivers/gpu/drm/bridge/sii902x.c  | 453 +-
>  include/dt-bindings/sound/sii902x-audio.h |  11 +
>  3 files changed, 493 insertions(+), 7 deletions(-)
>  create mode 100644 include/dt-bindings/sound/sii902x-audio.h
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt 
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> index 72d2dc6c3e6b..647b2fd84db9 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> @@ -5,9 +5,32 @@ Required properties:
>   - reg: i2c address of the bridge
>  
>  Optional properties:
> - - interrupts: describe the interrupt line used to inform the host 
> + - interrupts: describe the interrupt line used to inform the host
> about hotplug events.
>   - reset-gpios: OF device-tree gpio specification for RST_N pin.
> + - i2s-fifo-routing: Array of exactly 4 integers indicating i2s
> +   pins for audio fifo routing. First integer defines routing to
> +   fifo 0 and second to fifo 1, etc. Integers can be filled with
> +   definitions from: include/dt-bindings/sound/sii902x-audio.h
> +   The available definitions are:
> +   - ENABLE_BIT: enable this audio fifo
> +   - CONNECT_SD#: route audio input from SD0, SD1, SD2, or SD3 i2s
> +  data input pin
> +   - LEFT_RIGHT_SWAP_BIT: swap i2s input channels for this fifo
> +   I2S HDMI audio is configured only if this property is found.
> + - clocks: phandle mclk
> + - clock-names: "mclk"
> + Describes SII902x MCLK input. MCLK is used to produce
> + HDMI audio CTS values. This property is required if
> + "i2s-fifo-routing"-property is present. This property follows
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + consumer binding.
> + - #sound-dai-cells = <0>: ASoC codec dai available for simple-card
> + If audio properties are present sii902x provides an ASoC
> + codec component driver that can be used by other ASoC
> + components like simple-card. See binding document for
> + details:
> + Documentation/devicetree/bindings/sound/simple-card.txt


I am not an audio expert, so please forgive me if I make stupid mistakes :)

As I wrote previously, lack of DT connection between the bridge and the
audio producer looks for me as incomplete binding - hardware connection
is neither discoverable neither represented in DT. As I understand it
works because there is usually only one sound subsystem per board, and
there is only one hdmi output. Am I right?

But I guess boards with more than one hdmi output are not uncommon, how
do you discover topology in such case?


Regards

Andrzej


>  
>  Optional subnodes:
>   - video input: this subnode can contain a video input port node
> @@ -21,6 +44,17 @@ Example:
>   compatible = "sil,sii9022";
>   reg = <0x39>;
>   reset-gpios = <&pioA 1 0>;
> +
> + #sound-dai-cells = <0>;
> + i2s-fifo-routing = <
> + (ENABLE_BIT|CONNECT_SD0)
> + 0
> + 0
> + 0
> + >;
> + clocks = <&mclk>;
> + clock-names = "mclk";
> +
>   ports {
>   #address-cells = <1>;
>   #size-cells = <0>;
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index 1e91ed72..2be27bc54fb5 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -27,12 +27,16 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
>  #include 
>  #include 
>  
> +#include 
> +#include 
> +
>  #define SII902X_TPI_VIDEO_DATA   0x0
>  
>  #define SII902X_TPI_PIXEL_REPETITION 0x8
> @@ -74,6 +78,77 @@
>  #define SII902X_AVI_POWER_STATE_MSK  GENMASK(1, 0)
>  #define SII902X_AVI_POWER_STATE_D(l) ((l) & 
> SII902X_AVI_POWER_STATE_MSK)
>  
> +/* Audio  */
> +#define SII902X_TPI_I2S_ENABLE_MAPPING_REG   0x1f
> +#define SII902X_TPI_I2S_CONFIG_FIFO0 (0 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO1 (1 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO2 (2 << 0)
> +#define SII902X_TPI_I2S_CONFIG_FIFO3 (3 << 0)
> +#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP  (1 << 2)
> +#define SII902X_TPI_I2S_AUTO_DOWNSAMPLE  (1 << 3)
> +#define SII902X_TP

Re: [PATCH 1/9] drm/bridge: tc358767: Simplify tc_poll_timeout()

[Andrzej Hajda]

On 26.02.2019 20:36, Andrey Smirnov wrote:
> Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
> the code for regmap_read_poll_timeout(). Replace copied code with a
> call to the original. No functional change intended.
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 19 +++
>  1 file changed, 3 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index e6403b9549f1..b0f8264a1285 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -252,24 +252,11 @@ static inline int tc_poll_timeout(struct regmap *map, 
> unsigned int addr,
> unsigned int cond_value,
> unsigned long sleep_us, u64 timeout_us)
>  {
> - ktime_t timeout = ktime_add_us(ktime_get(), timeout_us);
>   unsigned int val;
> - int ret;
>  
> - for (;;) {
> - ret = regmap_read(map, addr, &val);
> - if (ret)
> - break;
> - if ((val & cond_mask) == cond_value)
> - break;
> - if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) {
> - ret = regmap_read(map, addr, &val);
> - break;
> - }
> - if (sleep_us)
> - usleep_range((sleep_us >> 2) + 1, sleep_us);
> - }
> - return ret ?: (((val & cond_mask) == cond_value) ? 0 : -ETIMEDOUT);
> + return regmap_read_poll_timeout(map, addr, val,
> + (val & cond_mask) == cond_value,
> + sleep_us, timeout_us);
>  }
>  
>  static int tc_aux_wait_busy(struct tc_data *tc, unsigned int timeout_ms)


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

[Bug 202735] CONFIG_DRM_TTM does not have name in Kconfig, so it is invisble for menuconfig

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
Sounds rather like vboxvideo needs to autoselect TTM as well.

-- 
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

Re: [PATCH libdrm] libkms: update list of intel_drivers for Android build

[Eric Engestrom]

On Monday, 2019-03-04 08:28:25 +0200, Tapani Pälli wrote:
> ping!

Reviewed-by: Eric Engestrom 

> 
> On 2/21/19 8:56 AM, Tapani Pälli wrote:
> > Add new iris driver, remove deprecated ilo driver.
> > 
> > Signed-off-by: Tapani Pälli 
> > ---
> >   libkms/Android.mk | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libkms/Android.mk b/libkms/Android.mk
> > index 0be72054..a8b9489f 100644
> > --- a/libkms/Android.mk
> > +++ b/libkms/Android.mk
> > @@ -1,6 +1,6 @@
> >   DRM_GPU_DRIVERS := $(strip $(filter-out swrast, $(BOARD_GPU_DRIVERS)))
> > -intel_drivers := i915 i965 i915g ilo
> > +intel_drivers := i915 i965 i915g iris
> >   radeon_drivers := r300g r600g radeonsi
> >   nouveau_drivers := nouveau
> >   virgl_drivers := virgl
> > 
> ___
> 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] [v3, 2/2] drm/panel: Add Boe Himax8279d MIPI-DSI LCD panel

[Sam Ravnborg]

Hi Jerry

I can see two mails with identical subject and both v3 but with slightly 
different content
To help us please send a v4 with:
- changelog that identifies what was done in v2, v3, v4
- subjects that are not identical
- and please copy all people that provided review feedback

Then we can better help you so we can get this fine driver reviewed and ready 
for mainline.

Thanks in advance,

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

Re: [Intel-gfx] [PATCH v2 2/2] drm: i915: Switch to bitmap_zalloc()

[Chris Wilson]

Quoting Andy Shevchenko (2019-03-04 09:29:08)
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.

Which is confusing; since we explicitly want unsigned longs, not some
amorphous bitmap type.

> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/gpu/drm/i915/i915_gem.c   | 2 +-
>  drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
>  drivers/gpu/drm/i915/i915_gem_tiling.c| 6 +++---
>  drivers/gpu/drm/i915/selftests/intel_uncore.c | 5 ++---
>  4 files changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6728ea5c71d4..0d96520cfdb3 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4410,7 +4410,7 @@ static void __i915_gem_free_objects(struct 
> drm_i915_private *i915,
> drm_gem_object_release(&obj->base);
> i915_gem_info_remove_obj(i915, obj->base.size);
>  
> -   kfree(obj->bit_17);
> +   bitmap_free(obj->bit_17);
> i915_gem_object_free(obj);
>  
> GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
> b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> index e037e94792f3..1f880e5b79b0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> @@ -790,8 +790,7 @@ i915_gem_object_save_bit_17_swizzle(struct 
> drm_i915_gem_object *obj,
> int i;
>  
> if (obj->bit_17 == NULL) {
> -   obj->bit_17 = kcalloc(BITS_TO_LONGS(page_count),
> - sizeof(long), GFP_KERNEL);
> +   obj->bit_17 = bitmap_zalloc(page_count, GFP_KERNEL);

That feels a bit more of an overreach, as we just use bitops and never
actually use the bitmap iface.

Simply because it kills BITS_TO_LONGS(), even though I do not see why
the bitmap_[z]alloc and bitmap_free are not inlines...

And for this is not the overflow protection of kcalloc silly? We start
with a large value, factorise it, then check that the two factors do not
overflow? If it were to overflow, it would overflow in the
BITS_TO_LONGS() itself.

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

Re: [PATCH 2/9] drm/bridge: tc358767: Simplify tc_stream_clock_calc()

[Andrzej Hajda]

On 26.02.2019 20:36, Andrey Smirnov wrote:
> Drop the use of tc_write() as well as "magicly" used "ret" and "err:"
> and replace it with a simple call to regmap_write(). No functional
> change intended.
>
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index b0f8264a1285..86ebd49194b7 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -504,7 +504,6 @@ static int tc_pxl_pll_dis(struct tc_data *tc)
>  
>  static int tc_stream_clock_calc(struct tc_data *tc)
>  {
> - int ret;
>   /*
>* If the Stream clock and Link Symbol clock are
>* asynchronous with each other, the value of M changes over
> @@ -520,11 +519,7 @@ static int tc_stream_clock_calc(struct tc_data *tc)
>* M/N = f_STRMCLK / f_LSCLK
>*
>*/
> - tc_write(DP0_VIDMNGEN1, 32768);
> -
> - return 0;
> -err:
> - return ret;
> + return regmap_write(tc->regmap, DP0_VIDMNGEN1, 32768);


The patch looks semantically correct, but you are dropping here custom
accessor (tc_write) in favor of regmap API.

I think the best would be consistent across the whole driver: either use
only  accessors, either drop them entirely and use regmap API.

And it would be good to have comment of the original authors about this
change.


Regards

Andrzej


>  }
>  
>  static int tc_aux_link_setup(struct tc_data *tc)


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

Re: [Intel-gfx] [PATCH v2 1/2] drm/selftests/mm: Switch to bitmap_zalloc()

[Chris Wilson]

Quoting Andy Shevchenko (2019-03-04 09:29:07)
> Switch to bitmap_zalloc() to show clearly what we are allocating.
> Besides that it returns pointer of bitmap type instead of opaque void *.
> 
> Signed-off-by: Andy Shevchenko 
Reviewed-by: Chris Wilson 
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202735] CONFIG_DRM_TTM does not have name in Kconfig, so it is invisble for menuconfig

[bugzilla-daemon]

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

--- Comment #2 from Ilya (kazakevichi...@gmail.com) ---
Virtualbox is not part of Linux source tree. 
Threre is an .iso file for each VBox version that contains sources and script
to compile it against your kernel

-- 
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

Re: [Intel-gfx] [PATCH v2 2/2] drm: i915: Switch to bitmap_zalloc()

[Chris Wilson]

Quoting Andy Shevchenko (2019-03-04 09:54:46)
> On Mon, Mar 04, 2019 at 09:41:34AM +, Chris Wilson wrote:
> > Quoting Andy Shevchenko (2019-03-04 09:29:08)
> > > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > > Besides that it returns pointer of bitmap type instead of opaque void *.
> > 
> > Which is confusing; since we explicitly want unsigned longs, not some
> > amorphous bitmap type.
> 
> Why? You use it as a bitmap anyway since you are telling below you are using
> bit ops like set/clear_bit.

I consider that bitmap sits on on top of the bitops iface and so we
should be using the types as defined by bitops. The allusion of "return
pointer of bitmap type" is that it may become an abstract type, ill
suited for the actual use. Just concerns over inferred language.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vmwgfx: Don't double-free the mode stored in par->set_mode

[Thomas Zimmermann]

When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing 'old_mode'
in favor of using par->set_mode directly fixes the problem.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
index b913a56f3426..2a9112515f46 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
@@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info *info)
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
};
-   struct drm_display_mode *old_mode;
struct drm_display_mode *mode;
int ret;
 
-   old_mode = par->set_mode;
mode = drm_mode_duplicate(vmw_priv->dev, &new_mode);
if (!mode) {
DRM_ERROR("Could not create new fb mode.\n");
@@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info *info)
mode->vdisplay = var->yres;
vmw_guess_mode_timing(mode);
 
-   if (old_mode && drm_mode_equal(old_mode, mode)) {
-   drm_mode_destroy(vmw_priv->dev, mode);
-   mode = old_mode;
-   old_mode = NULL;
-   } else if (!vmw_kms_validate_mode_vram(vmw_priv,
+   if (!vmw_kms_validate_mode_vram(vmw_priv,
mode->hdisplay *
DIV_ROUND_UP(var->bits_per_pixel, 8),
mode->vdisplay)) {
@@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info *info)
schedule_delayed_work(&par->local_work, 0);
 
 out_unlock:
-   if (old_mode)
-   drm_mode_destroy(vmw_priv->dev, old_mode);
+   if (par->set_mode)
+   drm_mode_destroy(vmw_priv->dev, par->set_mode);
par->set_mode = mode;
 
mutex_unlock(&par->bo_mutex);
-- 
2.20.1

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

[Bug 107956] [CI][SHARDS] igt@kms_busy@extended_*_render-[abc] - dmesg-warn - Asynchronous wait on fence i915:kms_busy\[\d+\]/0:1 timed out \(hint:intel_atomic_commit_ready

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=107956

Petri Latvala  changed:

   What|Removed |Added

 QA Contact||intel-gfx-bugs@lists.freede
   ||sktop.org
  Component|IGT |DRM/Intel
  i915 features|display/Other   |CI Infra
   Assignee|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede
   |.org|sktop.org

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

[PATCH v3] dt-bindings: gpu: add bindings for the ARM Mali Bifrost GPU

[Neil Armstrong]

Add the bindings for the Bifrost family of ARM Mali GPUs.

The Bifrost GPU architecture is similar to the Midgard family,
but with a different Shader Core & Execution Engine structures.

Bindings are based on the Midgard family bindings, but the inner
architectural changes makes it a separate family needing separate
bindings.

The Bifrost GPUs are present in a number of recent SoCs, like the
Amlogic G12A Family, and many other vendors.
The Amlogic vendor specific compatible is added to handle the
specific IP integration differences and dependencies.

Signed-off-by: Neil Armstrong 
---
 .../bindings/gpu/arm,mali-bifrost.txt | 90 +++
 1 file changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt

Changes since v2:
- moved to a single compatible since HW is fully discoverable

diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt 
b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
new file mode 100644
index ..e068fccf4ce9
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.txt
@@ -0,0 +1,90 @@
+ARM Mali Bifrost GPU
+
+
+Required properties:
+
+- compatible :
+  * Must contain one the following:
++ "arm,mali-bifrost"
+  * which must be preceded by one of the following vendor specifics:
++ "amlogic,meson-g12a-mali"
+
+- reg : Physical base address of the device and length of the register area.
+
+- interrupts : Contains the three IRQ lines required by Mali Bifrost devices.
+
+- interrupt-names : Contains the names of IRQ resources in the order they were
+  provided in the interrupts property. Must contain: "job", "mmu", "gpu".
+
+Optional properties:
+
+- clocks : Phandle to clock for the Mali Bifrost device.
+
+- mali-supply : Phandle to regulator for the Mali device. Refer to
+  Documentation/devicetree/bindings/regulator/regulator.txt for details.
+
+- operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt
+  for details.
+
+- resets : Phandle of the GPU reset line.
+
+Vendor-specific bindings
+
+
+The Mali GPU is integrated very differently from one SoC to
+another. In order to accomodate those differences, you have the option
+to specify one more vendor-specific compatible, among:
+
+- "amlogic,meson-g12a-mali"
+  Required properties:
+  - resets : Should contain phandles of :
++ GPU reset line
++ GPU APB glue reset line
+
+Example for a Mali-G31:
+
+gpu@ffa3 {
+   compatible = "amlogic,meson-g12a-mali", "arm,mali-bifrost";
+   reg = <0xffe4 0x1>;
+   interrupts = ,
+,
+;
+   interrupt-names = "job", "mmu", "gpu";
+   clocks = <&clk CLKID_MALI>;
+   mali-supply = <&vdd_gpu>;
+   operating-points-v2 = <&gpu_opp_table>;
+   resets = <&reset RESET_DVALIN_CAPB3>, <&reset RESET_DVALIN>;
+};
+
+gpu_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+
+   opp@53300 {
+   opp-hz = /bits/ 64 <53300>;
+   opp-microvolt = <125>;
+   };
+   opp@45000 {
+   opp-hz = /bits/ 64 <45000>;
+   opp-microvolt = <115>;
+   };
+   opp@4 {
+   opp-hz = /bits/ 64 <4>;
+   opp-microvolt = <1125000>;
+   };
+   opp@35000 {
+   opp-hz = /bits/ 64 <35000>;
+   opp-microvolt = <1075000>;
+   };
+   opp@26600 {
+   opp-hz = /bits/ 64 <26600>;
+   opp-microvolt = <1025000>;
+   };
+   opp@16000 {
+   opp-hz = /bits/ 64 <16000>;
+   opp-microvolt = <925000>;
+   };
+   opp@1 {
+   opp-hz = /bits/ 64 <1>;
+   opp-microvolt = <912500>;
+   };
+};
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH v1 1/2] drm/selftests/mm: Switch to bitmap_zalloc()

[kbuild test robot]

Hi Andy,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.0 next-20190301]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/drm-selftests-mm-Switch-to-bitmap_zalloc/20190304-183335
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: nds32-allyesconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 6.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=6.4.0 make.cross ARCH=nds32 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/selftests/test-drm_mm.c: In function 'igt_bottomup':
>> drivers/gpu/drm/selftests/test-drm_mm.c:1747:11: error: implicit declaration 
>> of function 'bitmap_zcalloc' [-Werror=implicit-function-declaration]
 bitmap = bitmap_zcalloc(count, GFP_KERNEL);
  ^~
>> drivers/gpu/drm/selftests/test-drm_mm.c:1747:9: warning: assignment makes 
>> pointer from integer without a cast [-Wint-conversion]
 bitmap = bitmap_zcalloc(count, GFP_KERNEL);
^
   cc1: some warnings being treated as errors

vim +/bitmap_zcalloc +1747 drivers/gpu/drm/selftests/test-drm_mm.c

  1725  
  1726  static int igt_bottomup(void *ignored)
  1727  {
  1728  const struct insert_mode *bottomup = &insert_modes[BOTTOMUP];
  1729  DRM_RND_STATE(prng, random_seed);
  1730  const unsigned int count = 8192;
  1731  unsigned int size;
  1732  unsigned long *bitmap;
  1733  struct drm_mm mm;
  1734  struct drm_mm_node *nodes, *node, *next;
  1735  unsigned int *order, n, m, o = 0;
  1736  int ret;
  1737  
  1738  /* Like igt_topdown, but instead of searching for the last hole,
  1739   * we search for the first.
  1740   */
  1741  
  1742  ret = -ENOMEM;
  1743  nodes = vzalloc(array_size(count, sizeof(*nodes)));
  1744  if (!nodes)
  1745  goto err;
  1746  
> 1747  bitmap = bitmap_zcalloc(count, GFP_KERNEL);
  1748  if (!bitmap)
  1749  goto err_nodes;
  1750  
  1751  order = drm_random_order(count, &prng);
  1752  if (!order)
  1753  goto err_bitmap;
  1754  
  1755  ret = -EINVAL;
  1756  for (size = 1; size <= 64; size <<= 1) {
  1757  drm_mm_init(&mm, 0, size*count);
  1758  for (n = 0; n < count; n++) {
  1759  if (!expect_insert(&mm, &nodes[n],
  1760 size, 0, n,
  1761 bottomup)) {
  1762  pr_err("bottomup insert failed, size %u 
step %d\n", size, n);
  1763  goto out;
  1764  }
  1765  
  1766  if (!assert_one_hole(&mm, size*(n + 1), 
size*count))
  1767  goto out;
  1768  }
  1769  
  1770  if (!assert_continuous(&mm, size))
  1771  goto out;
  1772  
  1773  drm_random_reorder(order, count, &prng);
  1774  for_each_prime_number_from(n, 1, min(count, max_prime)) 
{
  1775  for (m = 0; m < n; m++) {
  1776  node = &nodes[order[(o + m) % count]];
  1777  drm_mm_remove_node(node);
  1778  __set_bit(node_index(node), bitmap);
  1779  }
  1780  
  1781  for (m = 0; m < n; m++) {
  1782  unsigned int first;
  1783  
  1784  node = &nodes[order[(o + m) % count]];
  1785  if (!expect_insert(&mm, node,
  1786 size, 0, 0,
  1787 bottomup)) {
  1788  pr_err("insert failed, step 
%d/%d\n", m, n);
  1789  goto out;
  1790  }
  1791  
  1792  first = find_first_bit(bitmap, count);
  1793  if (node_index(node) != first) {
  1794  pr_err("node %d/%d not inserted 
into bottom hole, expected %d, found %d\n",
  1795   

Re: [PATCH 5/7] pwm: atmel-hlcdc: add compatible for SAM9X60 HLCDC's PWM

[Thierry Reding]

On Wed, Feb 27, 2019 at 04:24:35PM +, claudiu.bez...@microchip.com wrote:
> From: Claudiu Beznea 
> 
> Add compatible string for SAM9X60 HLCDC's PWM.
> 
> Signed-off-by: Claudiu Beznea 
> ---
>  drivers/pwm/pwm-atmel-hlcdc.c | 3 +++
>  1 file changed, 3 insertions(+)

I guess it makes more sense for this to go in with the MFD changes
rather than through the PWM tree, so:

Acked-by: Thierry Reding 


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

Re: [Intel-gfx] [PATCH v1 1/2] drm/selftests/mm: Switch to bitmap_zalloc()

[kbuild test robot]

Hi Andy,

I love your patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.0 next-20190301]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Andy-Shevchenko/drm-selftests-mm-Switch-to-bitmap_zalloc/20190304-183335
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.2.0 make.cross ARCH=xtensa 

All error/warnings (new ones prefixed by >>):

   drivers/gpu//drm/selftests/test-drm_mm.c: In function 'igt_bottomup':
>> drivers/gpu//drm/selftests/test-drm_mm.c:1747:11: error: implicit 
>> declaration of function 'bitmap_zcalloc'; did you mean 'bitmap_zalloc'? 
>> [-Werror=implicit-function-declaration]
 bitmap = bitmap_zcalloc(count, GFP_KERNEL);
  ^~
  bitmap_zalloc
>> drivers/gpu//drm/selftests/test-drm_mm.c:1747:9: warning: assignment to 
>> 'long unsigned int *' from 'int' makes pointer from integer without a cast 
>> [-Wint-conversion]
 bitmap = bitmap_zcalloc(count, GFP_KERNEL);
^
   cc1: some warnings being treated as errors

vim +1747 drivers/gpu//drm/selftests/test-drm_mm.c

  1725  
  1726  static int igt_bottomup(void *ignored)
  1727  {
  1728  const struct insert_mode *bottomup = &insert_modes[BOTTOMUP];
  1729  DRM_RND_STATE(prng, random_seed);
  1730  const unsigned int count = 8192;
  1731  unsigned int size;
  1732  unsigned long *bitmap;
  1733  struct drm_mm mm;
  1734  struct drm_mm_node *nodes, *node, *next;
  1735  unsigned int *order, n, m, o = 0;
  1736  int ret;
  1737  
  1738  /* Like igt_topdown, but instead of searching for the last hole,
  1739   * we search for the first.
  1740   */
  1741  
  1742  ret = -ENOMEM;
  1743  nodes = vzalloc(array_size(count, sizeof(*nodes)));
  1744  if (!nodes)
  1745  goto err;
  1746  
> 1747  bitmap = bitmap_zcalloc(count, GFP_KERNEL);
  1748  if (!bitmap)
  1749  goto err_nodes;
  1750  
  1751  order = drm_random_order(count, &prng);
  1752  if (!order)
  1753  goto err_bitmap;
  1754  
  1755  ret = -EINVAL;
  1756  for (size = 1; size <= 64; size <<= 1) {
  1757  drm_mm_init(&mm, 0, size*count);
  1758  for (n = 0; n < count; n++) {
  1759  if (!expect_insert(&mm, &nodes[n],
  1760 size, 0, n,
  1761 bottomup)) {
  1762  pr_err("bottomup insert failed, size %u 
step %d\n", size, n);
  1763  goto out;
  1764  }
  1765  
  1766  if (!assert_one_hole(&mm, size*(n + 1), 
size*count))
  1767  goto out;
  1768  }
  1769  
  1770  if (!assert_continuous(&mm, size))
  1771  goto out;
  1772  
  1773  drm_random_reorder(order, count, &prng);
  1774  for_each_prime_number_from(n, 1, min(count, max_prime)) 
{
  1775  for (m = 0; m < n; m++) {
  1776  node = &nodes[order[(o + m) % count]];
  1777  drm_mm_remove_node(node);
  1778  __set_bit(node_index(node), bitmap);
  1779  }
  1780  
  1781  for (m = 0; m < n; m++) {
  1782  unsigned int first;
  1783  
  1784  node = &nodes[order[(o + m) % count]];
  1785  if (!expect_insert(&mm, node,
  1786 size, 0, 0,
  1787 bottomup)) {
  1788  pr_err("insert failed, step 
%d/%d\n", m, n);
  1789  goto out;
  1790  }
  1791  
  1792  first = find_first_bit(bitmap, count);
  1793  if (node_index(node) != first) {
  1794

[PATCH 0/6] Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats

[Swati Sharma]

This patch series is for enabling P0xx, Y2xx and Y4xx pixel formats for
intel's i915 driver.

In this patch series, Juha Pekka's patch series Gen10+ P0xx formats
https://patchwork.freedesktop.org/series/56053/ is combined with Swati's
https://patchwork.freedesktop.org/series/55035/ for Gen11+ pixel formats
(Y2xx and Y4xx).

P0xx pixel formats are enabled from GLK whereas Y2xx and Y4xx are enabled
from ICL platform.

These patches enable planar formats YUV420-P010, P012 and  P016
(Intial 3 patches of Juha) for GLK+ platform and packed format YUV422-Y210,
Y212 and Y216 and YUV444-Y410, Y412, Y416 for 10, 12 and 16 bits for ICL+
platforms.

IGT validating all these pixel formats is written by Maarten Lankhorst 
https://patchwork.freedesktop.org/patch/284508/

IGT needs libraries for pixman and cairo to support more than 8bpc. Need 
cairo >= 1.17.2 and pixman-1 >= 0.36.0.

Tested with custom cairo and pixman. P0xx and Y2xx successfully validated for
HDR planes, SDR planes having CRC mismatch (known bug for all YUV formats).

v3: fixed missing tab for XYUV (JP)

Juha-Pekka Heikkila (3):
  drm/i915: Add P010, P012, P016 plane control definitions
  drm/i915: Preparations for enabling P010, P012, P016 formats
  drm/i915: Enable P010, P012, P016 formats for primary and sprite
planes

Swati Sharma (3):
  drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
  drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control
definitions
  drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for
universal planes

 drivers/gpu/drm/drm_fourcc.c  |   6 ++
 drivers/gpu/drm/i915/i915_reg.h   |   9 +++
 drivers/gpu/drm/i915/intel_atomic_plane.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c  |  57 ++--
 drivers/gpu/drm/i915/intel_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_pm.c   |  14 ++--
 drivers/gpu/drm/i915/intel_sprite.c   | 108 --
 include/uapi/drm/drm_fourcc.h |  16 +
 8 files changed, 194 insertions(+), 19 deletions(-)

-- 
1.9.1

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

[PATCH 4/6] drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc

[Swati Sharma]

The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.

Y210:   For each component, valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212:   For each component, valid data occupies MSB 12 bits.
LSB 4 bits are filled with zeroes.
Y216:   For each component valid data occupies 16 bits,
doesn't require any padding bits.

First 16 bits stores the Y value and the next 16 bits stores one
of the chroma samples alternatively. The first luma sample will
be accompanied by first U sample and second luma sample is
accompanied by the first V sample.

The following pixel formats are packed format that follows 4:4:4
chroma sampling. Channels are arranged in the order UYVA in
increasing memory order.

Y410:   Each color component occupies 10 bits and X component
takes 2 bits, thus each pixel occupies 32 bits.
Y412:   Each color component is 16 bits where valid data
occupies MSB 12 bits. LSB 4 bits are filled with zeroes.
Thus, each pixel occupies 64 bits.
Y416:   Each color component occupies 16 bits for valid data,
doesn't require any padding bits. Thus, each pixel
occupies 64 bits.

v3: fixed missing tab for XYUV (JP)

Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
Reviewed-by: Juha-Pekka Heikkila 
---
 drivers/gpu/drm/drm_fourcc.c  |  6 ++
 include/uapi/drm/drm_fourcc.h | 16 
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index ba7e19d..45c9882 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -226,6 +226,12 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_XYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
+   { .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y212,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y216,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y412,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y416,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,  
.num_planes = 1,
  .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 }, 
.block_h = { 2, 0, 0 },
  .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index bab2029..9fa7cf7 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -154,6 +154,22 @@
 #define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /* 
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
 
 /*
+ * packed Y2xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb
+ */
+#define DRM_FORMAT_Y210 fourcc_code('Y', '2', '1', '0') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 10:6:10:6:10:6:10:6 little endian per 2 Y pixels */
+#define DRM_FORMAT_Y212 fourcc_code('Y', '2', '1', '2') /* [63:0] 
Y0:x:Cb0:x:Y1:x:Cr1:x 12:4:12:4:12:4:12:4 little endian per 2 Y pixels */
+#define DRM_FORMAT_Y216 fourcc_code('Y', '2', '1', '6') /* [63:0] 
Y0:Cb0:Y1:Cr1 16:16:16:16 little endian per 2 Y pixels */
+
+/*
+ * packed Y4xx indicate for each component, xx valid data occupy msb
+ * 16-xx padding occupy lsb except Y410
+ */
+#define DRM_FORMAT_Y410 fourcc_code('Y', '4', '1', '0') /* [31:0] 
X:V:Y:U 2:10:10:10 little endian */
+#define DRM_FORMAT_Y412 fourcc_code('Y', '4', '1', '2') /* [63:0] 
X:x:V:x:Y:x:U:x 12:4:12:4:12:4:12:4 little endian */
+#define DRM_FORMAT_Y416 fourcc_code('Y', '4', '1', '6') /* [63:0] 
X:V:Y:U 16:16:16:16 little endian */
+
+/*
  * packed YCbCr420 2x2 tiled formats
  * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
  */
-- 
1.9.1

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

[PATCH 2/6] drm/i915: Preparations for enabling P010, P012, P016 formats

[Swati Sharma]

From: Juha-Pekka Heikkila 

Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_atomic_plane.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c  | 27 +--
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_pm.c   | 14 +++---
 drivers/gpu/drm/i915/intel_sprite.c   | 22 +++---
 5 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7961cf0..9d32a6f 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -136,7 +136,7 @@ int intel_plane_atomic_check_with_state(const struct 
intel_crtc_state *old_crtc_
new_crtc_state->active_planes |= BIT(plane->id);
 
if (new_plane_state->base.visible &&
-   new_plane_state->base.fb->format->format == DRM_FORMAT_NV12)
+   is_planar_yuv_format(new_plane_state->base.fb->format->format))
new_crtc_state->nv12_planes |= BIT(plane->id);
 
if (new_plane_state->base.visible &&
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7c5e84e..61ad775 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2681,6 +2681,12 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+   case PLANE_CTL_FORMAT_P010:
+   return DRM_FORMAT_P010;
+   case PLANE_CTL_FORMAT_P012:
+   return DRM_FORMAT_P012;
+   case PLANE_CTL_FORMAT_P016:
+   return DRM_FORMAT_P016;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3179,7 +3185,7 @@ int skl_check_plane_surface(struct intel_plane_state 
*plane_state)
 * Handle the AUX surface first since
 * the main surface setup depends on it.
 */
-   if (fb->format->format == DRM_FORMAT_NV12) {
+   if (is_planar_yuv_format(fb->format->format)) {
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
@@ -3604,6 +3610,12 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+   case DRM_FORMAT_P010:
+   return PLANE_CTL_FORMAT_P010;
+   case DRM_FORMAT_P012:
+   return PLANE_CTL_FORMAT_P012;
+   case DRM_FORMAT_P016:
+   return PLANE_CTL_FORMAT_P016;
default:
MISSING_CASE(pixel_format);
}
@@ -5027,9 +5039,9 @@ u16 skl_scaler_calc_phase(int sub, int scale, bool 
chroma_cosited)
return 0;
}
 
-   if (format && format->format == DRM_FORMAT_NV12 &&
+   if (format && is_planar_yuv_format(format->format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
-   DRM_DEBUG_KMS("NV12: src dimensions not met\n");
+   DRM_DEBUG_KMS("Planar YUV: src dimensions not met\n");
return -EINVAL;
}
 
@@ -5103,7 +5115,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
 
/* Pre-gen11 and SDR planes always need a scaler for planar formats. */
if (!icl_is_hdr_plane(intel_plane) &&
-   fb && fb->format->format == DRM_FORMAT_NV12)
+   fb && is_planar_yuv_format(fb->format->format))
need_scaler = true;
 
ret = skl_update_scaler(crtc_state, force_detach,
@@ -5140,6 +5152,9 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+   case DRM_FORMAT_P010:
+   case DRM_FORMAT_P012:
+   case DRM_FORMAT_P016:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
@@ -11191,7 +11206,7 @@ static int icl_check_nv12_planes(struct 
intel_crtc_state *crtc_state)
}
 
if (!linked_state) {
-   DRM_DEBUG_KMS("Need %d free Y planes for NV12\n",
+   DRM_DEBUG_KMS("Need %d free Y planes for planar YUV\n",
  hweight8(crtc_state->nv12_planes));
 
return -EINVAL;
@@ -13909,7 +13924,7 @@ static void fb_obj_bump_render_priority(struct 
drm_i915_gem_object *obj)
 *or
 *cdclk/crtc_clock
 */
-   mult = pixel_format == DRM_FORMAT_NV12 ? 2 : 3;
+   mult = is_plana

[PATCH 6/6] drm/i915/icl: Enabling Y2xx and Y4xx (xx:10/12/16) formats for universal planes

[Swati Sharma]

Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 30 ++
 drivers/gpu/drm/i915/intel_sprite.c  | 60 +++-
 2 files changed, 89 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 61ad775..6825267 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2687,6 +2687,18 @@ int skl_format_to_fourcc(int format, bool rgb_order, 
bool alpha)
return DRM_FORMAT_P012;
case PLANE_CTL_FORMAT_P016:
return DRM_FORMAT_P016;
+   case PLANE_CTL_FORMAT_Y210:
+   return DRM_FORMAT_Y210;
+   case PLANE_CTL_FORMAT_Y212:
+   return DRM_FORMAT_Y212;
+   case PLANE_CTL_FORMAT_Y216:
+   return DRM_FORMAT_Y216;
+   case PLANE_CTL_FORMAT_Y410:
+   return DRM_FORMAT_Y410;
+   case PLANE_CTL_FORMAT_Y412:
+   return DRM_FORMAT_Y412;
+   case PLANE_CTL_FORMAT_Y416:
+   return DRM_FORMAT_Y416;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3616,6 +3628,18 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_P012;
case DRM_FORMAT_P016:
return PLANE_CTL_FORMAT_P016;
+   case DRM_FORMAT_Y210:
+   return PLANE_CTL_FORMAT_Y210;
+   case DRM_FORMAT_Y212:
+   return PLANE_CTL_FORMAT_Y212;
+   case DRM_FORMAT_Y216:
+   return PLANE_CTL_FORMAT_Y216;
+   case DRM_FORMAT_Y410:
+   return PLANE_CTL_FORMAT_Y410;
+   case DRM_FORMAT_Y412:
+   return PLANE_CTL_FORMAT_Y412;
+   case DRM_FORMAT_Y416:
+   return PLANE_CTL_FORMAT_Y416;
default:
MISSING_CASE(pixel_format);
}
@@ -5155,6 +5179,12 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
+   case DRM_FORMAT_Y210:
+   case DRM_FORMAT_Y212:
+   case DRM_FORMAT_Y216:
+   case DRM_FORMAT_Y410:
+   case DRM_FORMAT_Y412:
+   case DRM_FORMAT_Y416:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 0db3c5d..89d7bf7 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1816,6 +1816,27 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_VYUY,
 };
 
+static const uint32_t icl_plane_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_Y210,
+   DRM_FORMAT_Y212,
+   DRM_FORMAT_Y216,
+   DRM_FORMAT_Y410,
+   DRM_FORMAT_Y412,
+   DRM_FORMAT_Y416,
+};
+
 static const u32 skl_planar_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -1851,6 +1872,31 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_P016,
 };
 
+static const uint32_t icl_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_P010,
+   DRM_FORMAT_P012,
+   DRM_FORMAT_P016,
+   DRM_FORMAT_Y210,
+   DRM_FORMAT_Y212,
+   DRM_FORMAT_Y216,
+   DRM_FORMAT_Y410,
+   DRM_FORMAT_Y412,
+   DRM_FORMAT_Y416,
+};
+
 static const u64 skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -1993,6 +2039,12 @@ static bool skl_plane_format_mod_supported(struct 
drm_plane *_plane,
case DRM_FORMAT_P010:
case DRM_FORMAT_P012:
case DRM_FORMAT_P016:
+   case DRM_FORMAT_Y210:
+   case DRM_FORMAT_Y212:
+   case DRM_FORMAT_Y216:
+   case DRM_FORMAT_Y410:
+   case DRM_FORMAT_Y412:
+   case DRM_FORMAT_Y416:
if (modifier == I915_FORMAT_MOD_Yf_TILED)
return true;
/* fall through */
@@ -2133,13 +2185,19 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
 
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
-   

[PATCH 1/6] drm/i915: Add P010, P012, P016 plane control definitions

[Swati Sharma]

From: Juha-Pekka Heikkila 

Add needed plane control flag definitions for P010, P012 and
P016 formats.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c9b482b..ce4ad20 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6602,8 +6602,11 @@ enum {
 #define   PLANE_CTL_FORMAT_YUV422  (0 << 24)
 #define   PLANE_CTL_FORMAT_NV12(1 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_2101010(2 << 24)
+#define   PLANE_CTL_FORMAT_P010(3 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_   (4 << 24)
+#define   PLANE_CTL_FORMAT_P012(5 << 24)
 #define   PLANE_CTL_FORMAT_XRGB_16161616F  (6 << 24)
+#define   PLANE_CTL_FORMAT_P016(7 << 24)
 #define   PLANE_CTL_FORMAT_AYUV(8 << 24)
 #define   PLANE_CTL_FORMAT_INDEXED (12 << 24)
 #define   PLANE_CTL_FORMAT_RGB_565 (14 << 24)
-- 
1.9.1

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

[PATCH 5/6] drm/i915/icl: Add Y2xx and Y4xx (xx:10/12/16) plane control definitions

[Swati Sharma]

Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and
16 bits)

Signed-off-by: Swati Sharma 
Signed-off-by: Vidya Srinivas 
Reviewed-by: Juha-Pekka Heikkila 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_reg.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ce4ad20..54bba61 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6612,6 +6612,12 @@ enum {
 #define   PLANE_CTL_FORMAT_RGB_565 (14 << 24)
 #define   ICL_PLANE_CTL_FORMAT_MASK(0x1f << 23)
 #define   PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
+#define   PLANE_CTL_FORMAT_Y210 (1 << 23)
+#define   PLANE_CTL_FORMAT_Y212 (3 << 23)
+#define   PLANE_CTL_FORMAT_Y216 (5 << 23)
+#define   PLANE_CTL_FORMAT_Y410 (7 << 23)
+#define   PLANE_CTL_FORMAT_Y412 (9 << 23)
+#define   PLANE_CTL_FORMAT_Y416 (0xb << 23)
 #define   PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
 #define   PLANE_CTL_KEY_ENABLE_SOURCE  (1 << 21)
 #define   PLANE_CTL_KEY_ENABLE_DESTINATION (2 << 21)
-- 
1.9.1

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

[PATCH 3/6] drm/i915: Enable P010, P012, P016 formats for primary and sprite planes

[Swati Sharma]

From: Juha-Pekka Heikkila 

Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.

Signed-off-by: Juha-Pekka Heikkila 
Signed-off-by: Swati Sharma 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_sprite.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 1be7d59..0db3c5d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1832,6 +1832,25 @@ int intel_sprite_set_colorkey_ioctl(struct drm_device 
*dev, void *data,
DRM_FORMAT_NV12,
 };
 
+static const uint32_t glk_planar_formats[] = {
+   DRM_FORMAT_C8,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_XBGR,
+   DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XBGR2101010,
+   DRM_FORMAT_YUYV,
+   DRM_FORMAT_YVYU,
+   DRM_FORMAT_UYVY,
+   DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
+   DRM_FORMAT_P010,
+   DRM_FORMAT_P012,
+   DRM_FORMAT_P016,
+};
+
 static const u64 skl_plane_format_modifiers_noccs[] = {
I915_FORMAT_MOD_Yf_TILED,
I915_FORMAT_MOD_Y_TILED,
@@ -2114,8 +2133,13 @@ struct intel_plane *
plane->update_slave = icl_update_slave;
 
if (skl_plane_has_planar(dev_priv, pipe, plane_id)) {
-   formats = skl_planar_formats;
-   num_formats = ARRAY_SIZE(skl_planar_formats);
+   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+   formats = glk_planar_formats;
+   num_formats = ARRAY_SIZE(glk_planar_formats);
+   } else {
+   formats = skl_planar_formats;
+   num_formats = ARRAY_SIZE(skl_planar_formats);
+   }
} else {
formats = skl_plane_formats;
num_formats = ARRAY_SIZE(skl_plane_formats);
-- 
1.9.1

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

Re: [PATCH 1/9] drm/bridge: tc358767: Simplify tc_poll_timeout()

[Laurent Pinchart]

Hi Andrey,

Thank you for the patch.

On Tue, Feb 26, 2019 at 11:36:01AM -0800, Andrey Smirnov wrote:
> Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
> the code for regmap_read_poll_timeout(). Replace copied code with a
> call to the original. No functional change intended.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/tc358767.c | 19 +++
>  1 file changed, 3 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index e6403b9549f1..b0f8264a1285 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -252,24 +252,11 @@ static inline int tc_poll_timeout(struct regmap *map, 
> unsigned int addr,
> unsigned int cond_value,
> unsigned long sleep_us, u64 timeout_us)
>  {
> - ktime_t timeout = ktime_add_us(ktime_get(), timeout_us);
>   unsigned int val;
> - int ret;
>  
> - for (;;) {
> - ret = regmap_read(map, addr, &val);
> - if (ret)
> - break;
> - if ((val & cond_mask) == cond_value)
> - break;
> - if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) {
> - ret = regmap_read(map, addr, &val);
> - break;
> - }
> - if (sleep_us)
> - usleep_range((sleep_us >> 2) + 1, sleep_us);
> - }
> - return ret ?: (((val & cond_mask) == cond_value) ? 0 : -ETIMEDOUT);
> + return regmap_read_poll_timeout(map, addr, val,
> + (val & cond_mask) == cond_value,
> + sleep_us, timeout_us);
>  }
>  
>  static int tc_aux_wait_busy(struct tc_data *tc, unsigned int timeout_ms)

-- 
Regards,

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

Re: [PATCH 2/9] drm/bridge: tc358767: Simplify tc_stream_clock_calc()

[Laurent Pinchart]

Hello,

On Mon, Mar 04, 2019 at 10:42:20AM +0100, Andrzej Hajda wrote:
> On 26.02.2019 20:36, Andrey Smirnov wrote:
> > Drop the use of tc_write() as well as "magicly" used "ret" and "err:"
> > and replace it with a simple call to regmap_write(). No functional
> > change intended.
> >
> > Signed-off-by: Andrey Smirnov 
> > Cc: Archit Taneja 
> > Cc: Andrzej Hajda 
> > Cc: Laurent Pinchart 
> > Cc: Chris Healy 
> > Cc: Lucas Stach 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-ker...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/bridge/tc358767.c | 7 +--
> >  1 file changed, 1 insertion(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> > b/drivers/gpu/drm/bridge/tc358767.c
> > index b0f8264a1285..86ebd49194b7 100644
> > --- a/drivers/gpu/drm/bridge/tc358767.c
> > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > @@ -504,7 +504,6 @@ static int tc_pxl_pll_dis(struct tc_data *tc)
> >  
> >  static int tc_stream_clock_calc(struct tc_data *tc)
> >  {
> > -   int ret;
> > /*
> >  * If the Stream clock and Link Symbol clock are
> >  * asynchronous with each other, the value of M changes over
> > @@ -520,11 +519,7 @@ static int tc_stream_clock_calc(struct tc_data *tc)
> >  * M/N = f_STRMCLK / f_LSCLK
> >  *
> >  */
> > -   tc_write(DP0_VIDMNGEN1, 32768);
> > -
> > -   return 0;
> > -err:
> > -   return ret;
> > +   return regmap_write(tc->regmap, DP0_VIDMNGEN1, 32768);
> 
> 
> The patch looks semantically correct, but you are dropping here custom
> accessor (tc_write) in favor of regmap API.
> 
> I think the best would be consistent across the whole driver: either use
> only  accessors, either drop them entirely and use regmap API.

I agree with this. The tc_write macro with its goto err is pretty nasty,
and I'd like to see it removed from the whole driver, or at least
replaced with an accessor that wouldn't hide the goto.

> And it would be good to have comment of the original authors about this
> change.
> 
> >  }
> >  
> >  static int tc_aux_link_setup(struct tc_data *tc)

-- 
Regards,

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

Re: [PATCH 3/9] drm/bridge: tc358767: Simplify tc_set_video_mode()

[Laurent Pinchart]

Hi Andrey,

Thank you for the patch.

On Tue, Feb 26, 2019 at 11:36:03AM -0800, Andrey Smirnov wrote:
> Simplify tc_set_video_mode() by replacing repreated calls to
> tc_write()/regmap_write() with a single call regmap_multi_reg_write().
> No functional change intended.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 125 --
>  1 file changed, 65 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 86ebd49194b7..c85468fcc157 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -641,10 +641,6 @@ static int tc_get_display_props(struct tc_data *tc)
>  
>  static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode 
> *mode)
>  {
> - int ret;
> - int vid_sync_dly;
> - int max_tu_symbol;
> -
>   int left_margin = mode->htotal - mode->hsync_end;
>   int right_margin = mode->hsync_start - mode->hdisplay;
>   int hsync_len = mode->hsync_end - mode->hsync_start;
> @@ -653,76 +649,85 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
> drm_display_mode *mode)
>   int vsync_len = mode->vsync_end - mode->vsync_start;
>  
>   /*
> -  * Recommended maximum number of symbols transferred in a transfer unit:
> +  * Recommended maximum number of symbols transferred in a
> +  * transfer unit:
>* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
>*  (output active video bandwidth in bytes))
>* Must be less than tu_size.
>*/
> - max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
> -
> - dev_dbg(tc->dev, "set mode %dx%d\n",
> - mode->hdisplay, mode->vdisplay);
> - dev_dbg(tc->dev, "H margin %d,%d sync %d\n",
> - left_margin, right_margin, hsync_len);
> - dev_dbg(tc->dev, "V margin %d,%d sync %d\n",
> - upper_margin, lower_margin, vsync_len);
> - dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
> -
> + int max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
>  
> + /* DP Main Stream Attributes */
> + int vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
>   /*
>* LCD Ctl Frame Size
>* datasheet is not clear of vsdelay in case of DPI
>* assume we do not need any delay when DPI is a source of
>* sync signals
>*/
> - tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
> -  OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
> - tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */
> -  (ALIGN(hsync_len, 2) << 0));/* Hsync */
> - tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) |  /* H front porch */
> -  (ALIGN(mode->hdisplay, 2) << 0)); /* width */
> - tc_write(VTIM01, (upper_margin << 16) | /* V back porch */
> -  (vsync_len << 0)); /* Vsync */
> - tc_write(VTIM02, (lower_margin << 16) | /* V front porch */
> -  (mode->vdisplay << 0));/* height */
> - tc_write(VFUEN0, VFUEN);/* update settings */
> -
> + u32 vpctrl0 = (0 << 20) /* VSDELAY */ |
> +   OPXLFMT_RGB888 | FRMSYNC_DISABLED |
> +   MSF_DISABLED;
> + u32 htim01 = (ALIGN(left_margin, 2) << 16) | /* H back porch */
> +  (ALIGN(hsync_len, 2) << 0); /* Hsync */
> + u32 htim02 = (ALIGN(right_margin, 2) << 16) | /* H front porch */
> +  (ALIGN(mode->hdisplay, 2) << 0); /* width */
> + u32 vtim01 = (upper_margin << 16) | /* V back porch */
> +  (vsync_len << 0); /* Vsync */
> + u32 vtim02 = (lower_margin << 16) | /* V front porch */
> +  (mode->vdisplay << 0); /* height */
>   /* Test pattern settings */
> - tc_write(TSTCTL,
> -  (120 << 24) |  /* Red Color component value */
> -  (20 << 16) |   /* Green Color component value */
> -  (99 << 8) |/* Blue Color component value */
> -  (1 << 4) | /* Enable I2C Filter */
> -  (2 << 0) | /* Color bar Mode */
> -  0);
> -
> - /* DP Main Stream Attributes */
> - vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
> - tc_write(DP0_VIDSYNCDELAY,
> -  (max_tu_symbol << 16) |/* thresh_dly */
> -  (vid_sync_dly << 0));
> + u32 tstctl = (120 << 24) |  /* Red Color component value */
> +  (20 << 16)  |  /* Green Color component value */
> +  (99 <<  8)  |  /* Blue Color component value */
> +  (1 <<  4)   |  /* Enable I2C Filter */
> +  (2 <<  0); /* Color bar Mode 

Re: [PATCH 4/9] drm/bridge: tc358767: Simplify polling in tc_main_link_setup()

[Laurent Pinchart]

On Tue, Feb 26, 2019 at 11:36:04AM -0800, Andrey Smirnov wrote:
> Replace explicit polling loop with equivalent call to
> regmap_read_poll_timeout() for simplicity. No functional change
> intended.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/tc358767.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index c85468fcc157..6455e6484722 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -882,15 +882,11 @@ static int tc_main_link_setup(struct tc_data *tc)
>   dp_phy_ctrl &= ~(DP_PHY_RST | PHY_M1_RST | PHY_M0_RST);
>   tc_write(DP_PHY_CTRL, dp_phy_ctrl);
>  
> - timeout = 1000;
> - do {
> - tc_read(DP_PHY_CTRL, &value);
> - udelay(1);
> - } while ((!(value & PHY_RDY)) && (--timeout));
> -
> - if (timeout == 0) {
> + ret = regmap_read_poll_timeout(tc->regmap, DP_PHY_CTRL, value,
> +value & PHY_RDY, 1, 1000);
> + if (ret) {
>   dev_err(dev, "timeout waiting for phy become ready");
> - return -ETIMEDOUT;
> + return ret;
>   }
>  
>   /* Set misc: 8 bits per color */

-- 
Regards,

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

Re: [PATCH 5/9] drm/bridge: tc358767: Simplify polling in tc_link_training()

[Laurent Pinchart]

Hi Andrey,

Thank you for the patch.

On Tue, Feb 26, 2019 at 11:36:05AM -0800, Andrey Smirnov wrote:
> Replace explicit polling in tc_link_training() with equivalent call to
> regmap_read_poll_timeout() for simplicity. No functional change
> intended (not including slightly altered debug output).
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 14 +-
>  1 file changed, 5 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 6455e6484722..ea30cec4a0c3 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -735,7 +735,6 @@ static int tc_link_training(struct tc_data *tc, int 
> pattern)
>   const char * const *errors;
>   u32 srcctrl = tc_srcctrl(tc) | DP0_SRCCTRL_SCRMBLDIS |
> DP0_SRCCTRL_AUTOCORRECT;
> - int timeout;
>   int retry;
>   u32 value;
>   int ret;
> @@ -765,20 +764,17 @@ static int tc_link_training(struct tc_data *tc, int 
> pattern)
>   tc_write(DP0CTL, DP_EN);
>  
>   /* wait */
> - timeout = 1000;
> - do {
> - tc_read(DP0_LTSTAT, &value);
> - udelay(1);
> - } while ((!(value & LT_LOOPDONE)) && (--timeout));
> - if (timeout == 0) {
> + ret = regmap_read_poll_timeout(tc->regmap, DP0_LTSTAT, value,
> +value & LT_LOOPDONE, 1, 1000);
> + if (ret) {
>   dev_err(tc->dev, "Link training timeout!\n");
>   } else {
>   int pattern = (value >> 11) & 0x3;
>   int error = (value >> 8) & 0x7;
>  
>   dev_dbg(tc->dev,
> - "Link training phase %d done after %d uS: %s\n",
> - pattern, 1000 - timeout, errors[error]);
> + "Link training phase %d done: %s\n",
> + pattern, errors[error]);

It's probably not a big deal in this specific case, but in general it
can be useful to know how long the poll took. Any hope to enhance
regmap_read_poll_timeout() to return either the elapsed time or the
remaining timeout instead of 0 on success ?

>   if (pattern == DP_TRAINING_PATTERN_1 && error == 0)
>   break;
>   if (pattern == DP_TRAINING_PATTERN_2) {

-- 
Regards,

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

Re: [PATCH 6/9] drm/bridge: tc358767: Simplify error check in tc_aux_linx_setup()

[Laurent Pinchart]

Hi Andrey,

Thank you for the patch.

On Tue, Feb 26, 2019 at 11:36:06AM -0800, Andrey Smirnov wrote:
> Tc_poll_timeout() can only return -ETIMEDOUT, so checking for other
> errors is not necessary. Drop it. No functional change intended.

Is that true given patch 1/9 in this series ? regmap_read_poll_timeout()
can also return an error from regmap_read().

> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index ea30cec4a0c3..54ff95f66e30 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -569,11 +569,10 @@ static int tc_aux_link_setup(struct tc_data *tc)
>  
>   ret = tc_poll_timeout(tc->regmap, DP_PHY_CTRL, PHY_RDY, PHY_RDY, 1,
> 1000);
> - if (ret == -ETIMEDOUT) {
> + if (ret) {
>   dev_err(tc->dev, "Timeout waiting for PHY to become ready");
>   return ret;
> - } else if (ret)
> - goto err;
> + }
>  
>   /* Setup AUX link */
>   tc_write(DP0_AUXCFG1, AUX_RX_FILTER_EN |

-- 
Regards,

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

Re: [PATCH 7/9] drm/bridge: tc358767: Introduce tc_set_syspllparam()

[Laurent Pinchart]

Hi Andrey,

Thank you for the patch.

On Tue, Feb 26, 2019 at 11:36:07AM -0800, Andrey Smirnov wrote:
> Move common code converting clock rate to an appropriate constant and
> configuring SYS_PLLPARAM register into a separate routine and convert
> the rest of the code to use it. No functional change intended.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/tc358767.c | 50 +--
>  1 file changed, 20 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 54ff95f66e30..227f14cd2d3d 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -522,35 +522,42 @@ static int tc_stream_clock_calc(struct tc_data *tc)
>   return regmap_write(tc->regmap, DP0_VIDMNGEN1, 32768);
>  }
>  
> -static int tc_aux_link_setup(struct tc_data *tc)
> +static int tc_set_syspllparam(struct tc_data *tc)
>  {
>   unsigned long rate;
> - u32 value;
> - int ret;
> - u32 dp_phy_ctrl;
> + u32 pllparam = SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
>  
>   rate = clk_get_rate(tc->refclk);
>   switch (rate) {
>   case 3840:
> - value = REF_FREQ_38M4;
> + pllparam |= REF_FREQ_38M4;
>   break;
>   case 2600:
> - value = REF_FREQ_26M;
> + pllparam |= REF_FREQ_26M;
>   break;
>   case 1920:
> - value = REF_FREQ_19M2;
> + pllparam |= REF_FREQ_19M2;
>   break;
>   case 1300:
> - value = REF_FREQ_13M;
> + pllparam |= REF_FREQ_13M;
>   break;
>   default:
>   dev_err(tc->dev, "Invalid refclk rate: %lu Hz\n", rate);
>   return -EINVAL;
>   }
>  
> + return regmap_write(tc->regmap, SYS_PLLPARAM, pllparam);
> +}
> +
> +static int tc_aux_link_setup(struct tc_data *tc)
> +{
> + int ret;
> + u32 dp_phy_ctrl;
> +
>   /* Setup DP-PHY / PLL */
> - value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
> - tc_write(SYS_PLLPARAM, value);
> + ret = tc_set_syspllparam(tc);
> + if (ret)
> + return ret;
>  
>   dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN;
>   if (tc->link.base.num_lanes == 2)
> @@ -811,7 +818,6 @@ static int tc_main_link_setup(struct tc_data *tc)
>  {
>   struct drm_dp_aux *aux = &tc->aux;
>   struct device *dev = tc->dev;
> - unsigned int rate;
>   u32 dp_phy_ctrl;
>   int timeout;
>   u32 value;
> @@ -828,25 +834,9 @@ static int tc_main_link_setup(struct tc_data *tc)
>(tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
>((tc->link.base.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
>  
> - rate = clk_get_rate(tc->refclk);
> - switch (rate) {
> - case 3840:
> - value = REF_FREQ_38M4;
> - break;
> - case 2600:
> - value = REF_FREQ_26M;
> - break;
> - case 1920:
> - value = REF_FREQ_19M2;
> - break;
> - case 1300:
> - value = REF_FREQ_13M;
> - break;
> - default:
> - return -EINVAL;
> - }
> - value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
> - tc_write(SYS_PLLPARAM, value);
> + ret = tc_set_syspllparam(tc);
> + if (ret)
> + return ret;
>  
>   /* Setup Main Link */
>   dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN | PHY_M0_EN;
> -- 
> 2.20.1
> 

-- 
Regards,

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

Re: [PATCH 8/9] drm/bridge: tc358767: Introduce tc_pllupdate_pllen()

[Laurent Pinchart]

Hi Andrey,

Thank you for the patch.

On Tue, Feb 26, 2019 at 11:36:08AM -0800, Andrey Smirnov wrote:
> Tc_wait_pll_lock() is always called as a follow-up for updating

s/Tc/tc/

> PLLUPDATE and PLLEN bit of a given PLL control register. To simplify
> things, merge the two operation into a single helper function
> tc_pllupdate_pllen() and convert the rest of the code to use it. No
> functional change intended.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/tc358767.c | 36 +++
>  1 file changed, 22 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 227f14cd2d3d..239b3aaa255d 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -390,10 +390,18 @@ static u32 tc_srcctrl(struct tc_data *tc)
>   return reg;
>  }
>  
> -static void tc_wait_pll_lock(struct tc_data *tc)
> +static int tc_pllupdate_pllen(struct tc_data *tc, unsigned int pllctrl)
>  {
> + int ret;
> +
> + ret = regmap_write(tc->regmap, pllctrl, PLLUPDATE | PLLEN);
> + if (ret)
> + return ret;
> +
>   /* Wait for PLL to lock: up to 2.09 ms, depending on refclk */
>   usleep_range(3000, 6000);
> +
> + return 0;
>  }
>  
>  static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, u32 pixelclock)
> @@ -487,11 +495,7 @@ static int tc_pxl_pll_en(struct tc_data *tc, u32 refclk, 
> u32 pixelclock)
>(best_mul << 0));  /* Multiplier for PLL */
>  
>   /* Force PLL parameter update and disable bypass */
> - tc_write(PXL_PLLCTRL, PLLUPDATE | PLLEN);
> -
> - tc_wait_pll_lock(tc);
> -
> - return 0;
> + return tc_pllupdate_pllen(tc, PXL_PLLCTRL);
>  err:
>   return ret;
>  }
> @@ -568,11 +572,13 @@ static int tc_aux_link_setup(struct tc_data *tc)
>* Initially PLLs are in bypass. Force PLL parameter update,
>* disable PLL bypass, enable PLL
>*/
> - tc_write(DP0_PLLCTRL, PLLUPDATE | PLLEN);
> - tc_wait_pll_lock(tc);
> + ret = tc_pllupdate_pllen(tc, DP0_PLLCTRL);
> + if (ret)
> + return ret;
>  
> - tc_write(DP1_PLLCTRL, PLLUPDATE | PLLEN);
> - tc_wait_pll_lock(tc);
> + ret = tc_pllupdate_pllen(tc, DP1_PLLCTRL);
> + if (ret)
> + return ret;
>  
>   ret = tc_poll_timeout(tc->regmap, DP_PHY_CTRL, PHY_RDY, PHY_RDY, 1,
> 1000);
> @@ -846,11 +852,13 @@ static int tc_main_link_setup(struct tc_data *tc)
>   msleep(100);
>  
>   /* PLL setup */
> - tc_write(DP0_PLLCTRL, PLLUPDATE | PLLEN);
> - tc_wait_pll_lock(tc);
> + ret = tc_pllupdate_pllen(tc, DP0_PLLCTRL);
> + if (ret)
> + return ret;
>  
> - tc_write(DP1_PLLCTRL, PLLUPDATE | PLLEN);
> - tc_wait_pll_lock(tc);
> + ret = tc_pllupdate_pllen(tc, DP1_PLLCTRL);
> + if (ret)
> + return ret;
>  
>   /* PXL PLL setup */
>   if (tc_test_pattern) {

-- 
Regards,

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

Re: [PATCH 9/9] drm/bridge: tc358767: Drop tc_read() macro

[Laurent Pinchart]

Hi Andrey,

Thank you for the patch.

On Tue, Feb 26, 2019 at 11:36:09AM -0800, Andrey Smirnov wrote:
> There's only one place where tc_read() is used, so it doesn't save us
> much. Drop it. No functional change intended.
> 
> Signed-off-by: Andrey Smirnov 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Chris Healy 
> Cc: Lucas Stach 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/gpu/drm/bridge/tc358767.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/tc358767.c 
> b/drivers/gpu/drm/bridge/tc358767.c
> index 239b3aaa255d..3c574f1569aa 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -240,12 +240,6 @@ static inline struct tc_data *connector_to_tc(struct 
> drm_connector *c)
>   if (ret)\
>   goto err;   \
>   } while (0)
> -#define tc_read(reg, var)\
> - do {\
> - ret = regmap_read(tc->regmap, reg, var);\
> - if (ret)\
> - goto err;   \
> - } while (0)

While I really like removing the goto from the macro, I think we should
either have accessors for both read and write, or remove them
completely. How about just dropping the goto in this patch, and decide
separately whether to keep accessors or remove them ?

>  static inline int tc_poll_timeout(struct regmap *map, unsigned int addr,
> unsigned int cond_mask,
> @@ -337,8 +331,13 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
>   if (request == DP_AUX_I2C_READ || request == DP_AUX_NATIVE_READ) {
>   /* Read data */
>   while (i < size) {
> - if ((i % 4) == 0)
> - tc_read(DP0_AUXRDATA(i >> 2), &tmp);
> + if ((i % 4) == 0) {
> + ret = regmap_read(tc->regmap,
> +   DP0_AUXRDATA(i >> 2),
> +   &tmp);
> + if (ret)
> + goto err;

You can return ret directly here.

> + }
>   buf[i] = tmp & 0xff;
>   tmp = tmp >> 8;
>   i++;

-- 
Regards,

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

Re: [PATCH v2 0/5] drm/bridge: sii902x: HDMI-audio support and some fixes

[Laurent Pinchart]

Hi Jyri,

On Wed, Feb 27, 2019 at 11:54:18PM +0200, Jyri Sarha wrote:
> Changes since first version:
> - Moved reviewed patches to front:
>   - drm/bridge: sii902x: add input_bus_flags
>   - drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID
>   - drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
> - Added a new fix:
>   - drm/bridge: sii902x: Select I2C_MUX
> - Applied some review suggestions to
>   - drm/bridge: sii902x: Implement HDMI audio support
> - use clock-names property to name mclk
> - move comment describing added mutex to struct sii902x and improve it
> - cleanup sii902x_mute()
> - cleanup sii902x_select_mclk_div()
> - fix condition for checking ENABLE_BIT from i2s_fifo_routing in
>   sii902x_audio_codec_init()
> 
> Still to do
> 
> - Agree on i2s wires to HDMI audio fifo routing in dts. 
> 
>   The current scheme is quite straight forward, but there is maybe
>   there is even more straight forward solutions like:
> 
>   audio-fifo-enable = <1 1 1 1>;
>   audio-i2s-pin-to-fifo = <0 1 2 3>;
> 
>   Meaning that all fifos are enabled and SD0 is routed to fifo 0, SD1
>   to fifo 1, etc. I am not sure if the channel swap functionality
>   should show in dts binding.

Please forgive my lack of audio knowledge, but it this a system
description that should be encoded in DT, or a policy that should be
handled purely in software (either fully inside the kernel or with the
help of userspace) ?

> Jyri Sarha (4):
>   drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID
>   drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
>   drm/bridge: sii902x: Select I2C_MUX
>   drm/bridge: sii902x: Implement HDMI audio support
> 
> Tomi Valkeinen (1):
>   drm/bridge: sii902x: add input_bus_flags
> 
>  .../bindings/display/bridge/sii902x.txt   |  36 +-
>  drivers/gpu/drm/bridge/Kconfig|   1 +
>  drivers/gpu/drm/bridge/sii902x.c  | 472 +-
>  include/dt-bindings/sound/sii902x-audio.h |  11 +
>  4 files changed, 512 insertions(+), 8 deletions(-)
>  create mode 100644 include/dt-bindings/sound/sii902x-audio.h

-- 
Regards,

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

Re: [PATCH v2 1/5] drm/bridge: sii902x: add input_bus_flags

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.

On Wed, Feb 27, 2019 at 11:54:19PM +0200, Jyri Sarha wrote:
> From: Tomi Valkeinen 
> 
> The driver always sets InputBusFmt:EDGE to 0 (falling edge).
> 
> Add drm_bridge_timings's input_bus_flags to reflect that the bridge
> samples on falling edges.
> 
> Signed-off-by: Tomi Valkeinen 
> Signed-off-by: Jyri Sarha 
> Reviewed-by: Andrzej Hajda 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/bridge/sii902x.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index bfa902013aa4..1afa000141d5 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -459,6 +459,12 @@ static int sii902x_i2c_bypass_deselect(struct 
> i2c_mux_core *mux, u32 chan_id)
>   return 0;
>  }
>  
> +static const struct drm_bridge_timings default_sii902x_timings = {
> + .input_bus_flags = DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE
> +  | DRM_BUS_FLAG_SYNC_SAMPLE_NEGEDGE
> +  | DRM_BUS_FLAG_DE_HIGH,
> +};
> +

Should you add a comment where the drive sets the EDGE bit to 0 to state
that default_sii902x_timings should then be made dynamic ? I suppose it
would be hard to miss that though, so maybe it's overkill. In any case,

Reviewed-by: Laurent Pinchart 

>  static int sii902x_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
>  {
> @@ -529,6 +535,7 @@ static int sii902x_probe(struct i2c_client *client,
>  
>   sii902x->bridge.funcs = &sii902x_bridge_funcs;
>   sii902x->bridge.of_node = dev->of_node;
> + sii902x->bridge.timings = &default_sii902x_timings;
>   drm_bridge_add(&sii902x->bridge);
>  
>   i2c_set_clientdata(client, sii902x);

-- 
Regards,

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

[RFC PATCH 0/2] Add DRM panel driver for Ilitek ILI9341 based panels in parallel RGB mode

[Josef Lusticky]

These patches add panel driver for ili9341-based panels in parallel RGB mode.
The driver was developed for DispleyTech DT024CTFT LCD panel [1] which features 
ILI9341 chip [2].
The driver was tested on the Allwinner A13 (sun5i) platform.

The driver supports 240x320 pixel resolution with 18-bit RGB (6 wires per color)
and SPI control bus with Data/Command GPIO pin:
DisplayTech DT024CTFT panel is configured with the IM[0:3] pins
set to "1110" - see page 10 in datasheet [2].

The Data/Command GPIO is optional, however at the moment the driver requires it:
The display itself is capable of 9-bit SPI without the Data/Command GPIO.
Support for such configuration can be added later to the driver.

Optional HW reset gpio can be specified, otherwise SW reset command is used
during the initialization.

The ILI9341 displays have two command sets:
Level 1 conforms to MIPI specs
Level 2 is outside the MIPI specs - custom defines are used in the driver

The ILI9341 supports various RGB modes (e.g. NVSYNC, DE_LOW, clock freq, etc.),
however values that are presented in the ILI9341 datasheet [2] are used
by the driver in struct drm_display_mode.


General note on ILI9341-based displays:
The ILI9341 chip can be used in parallel RGB with SPI control
or in SPI only mode where the image data itself is also transferred via SPI.
This driver supports parallel RGB displays - it works with displays wired with 
18-bit RGB input,
it does not support SPI data mode (i.e. Multi-inno mi0283qt or Adafruit 
yx240qv29 are not supported by this driver).
The SPI data mode is naturally much slower than the parallel RGB mode.

General note on DisplayTech DT024CTFT panel:
The panel supports different configuation options (18/16/6-bit RGB or 9/8-bit 
SPI) depending on the IM[0:3] wiring.
To keep this patch small for reveiw, at the moment only 18-bit RGB mode and 
8-bit SPI with Data/Command GPIO
is supported by this driver.


I kindly ask you for a patch review.

Links to datasheet:
[1] 
https://www.displaytech-us.com/sites/default/files/display-data-sheet/DT024CTFT-v10_0.pdf
[2] https://cdn-shop.adafruit.com/datasheets/ILI9341.pdf

Best regards,
Josef Lusticky

Josef Lusticky (2):
  drm/panel: Add Ilitek ILI9341 parallel RGB panel driver
  dt-bindings: panel: Add Ilitek ILI9341 panel documentation

 .../bindings/display/panel/ilitek,ili9341.txt |  33 ++
 MAINTAINERS   |   6 +
 drivers/gpu/drm/panel/Kconfig |   7 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c  | 320 ++
 5 files changed, 367 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c

-- 
2.20.1

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

[RFC PATCH 2/2] dt-bindings: panel: Add Ilitek ILI9341 panel documentation

[Josef Lusticky]

---
 .../bindings/display/panel/ilitek,ili9341.txt | 33 +++
 1 file changed, 33 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt

diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt 
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
new file mode 100644
index ..4e0e483bc12e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
@@ -0,0 +1,33 @@
+Ilitek ILI9341 TFT panel driver with SPI control bus
+
+This is a driver for 240x320 TFT panels with parallel RGB color input.
+
+Required properties:
+  - compatible: "displaytech,dt024ctft", "ilitek,ili9341"
+  - backlight: phandle of the backlight device attached to the panel
+
+Optional properties:
+  - dc-gpios: a GPIO spec for the Data/Command pin, see gpio/gpio.txt
+  - reset-gpios: a GPIO spec for the reset pin, see gpio/gpio.txt
+
+The panel must obey the rules for a SPI slave device as specified in
+spi/spi-bus.txt
+
+The device node can contain one 'port' child node with one child
+'endpoint' node, according to the bindings defined in
+media/video-interfaces.txt. This node should describe panel's video bus.
+
+Example:
+
+panel@0 {
+   compatible = "displaytech,dt024ctft", "ilitek,ili9341";
+   reg = <0>;
+   backlight = <&backlight>;
+   dc-gpios = <&pio 4 9 GPIO_ACTIVE_HIGH>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <&display_out>;
+   };
+   };
+};
-- 
2.20.1

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

[RFC PATCH 1/2] drm/panel: Add Ilitek ILI9341 parallel RGB panel driver

[Josef Lusticky]

---
 MAINTAINERS  |   6 +
 drivers/gpu/drm/panel/Kconfig|   7 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 320 +++
 4 files changed, 334 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9341.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a4a4bf563f94..d2e03c5ad04d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4821,6 +4821,12 @@ S:   Maintained
 F: drivers/gpu/drm/tinydrm/ili9225.c
 F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
 
+DRM DRIVER FOR ILITEK ILI9341 PANELS
+M: Josef Lusticky 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+F: Documentation/devicetree/bindings/display/panel/ilitek,ili9341.txt
+
 DRM DRIVER FOR HX8357D PANELS
 M: Eric Anholt 
 T: git git://anongit.freedesktop.org/drm/drm-misc
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index f53f817356db..a59cfff614c0 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -46,6 +46,13 @@ config DRM_PANEL_ILITEK_IL9322
  Say Y here if you want to enable support for Ilitek IL9322
  QVGA (320x240) RGB, YUV and ITU-T BT.656 panels.
 
+config DRM_PANEL_ILITEK_IL9341
+   tristate "Ilitek ILI9341 240x320 panels"
+   depends on OF && SPI
+   help
+ Say Y here if you want to enable support for Ilitek IL9341
+ QVGA (240x320) RGB panel.
+
 config DRM_PANEL_ILITEK_ILI9881C
tristate "Ilitek ILI9881C-based panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 7834947a53b0..1ce3ff8d6204 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_PANEL_ARM_VERSATILE) += panel-arm-versatile.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_IL9341) += panel-ilitek-ili9341.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
new file mode 100644
index ..51ed03140f8d
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -0,0 +1,320 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Ilitek ILI9341 drm_panel driver
+ * 240RGBx320 dots resolution TFT LCD display
+ *
+ * This driver support the following panel configurations:
+ * - 18-bit parallel RGB interface
+ * - 8-bit SPI with Data/Command GPIO
+ *
+ * Copyright (C) 2019 Josef Lusticky 
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* ILI9341 extended register set */
+#define ILI9341_IFMODE 0xB0 // clock polarity
+#define ILI9341_IFCTL  0xF6 // interface conrol
+#define ILI9341_PGAMCTRL   0xE0 // positive gamma control
+#define ILI9341_NGAMCTRL   0xE1 // negative gamma control
+
+#define ILI9341_MADCTL_MV  BIT(5)
+#define ILI9341_MADCTL_MX  BIT(6)
+#define ILI9341_MADCTL_MY  BIT(7)
+
+/**
+ * struct ili9341_config - the display specific configuration
+ * @width_mm: physical panel width [mm]
+ * @height_mm: physical panel height [mm]
+ */
+struct ili9341_config {
+   u32 width_mm;
+   u32 height_mm;
+};
+
+struct ili9341 {
+   const struct ili9341_config *conf;
+   struct drm_panel panel;
+   struct spi_device *spi;
+   struct backlight_device *backlight;
+   struct gpio_desc *dc_gpio;
+   struct gpio_desc *reset_gpio;
+};
+
+static inline struct ili9341 *panel_to_ili9341(struct drm_panel *panel)
+{
+   return container_of(panel, struct ili9341, panel);
+}
+
+static int ili9341_spi_write_command(struct ili9341 *ili, u8 cmd)
+{
+   struct spi_transfer xfer = {
+   .tx_buf = &cmd,
+   .bits_per_word = 8,
+   .len = 1
+   };
+   struct spi_message msg;
+   spi_message_init(&msg);
+   spi_message_add_tail(&xfer, &msg);
+
+   gpiod_set_value(ili->dc_gpio, 0);
+
+   return spi_sync(ili->spi, &msg);
+}
+
+static int ili9341_spi_write_data(struct ili9341 *ili, u8 *data, size_t size)
+{
+   struct spi_transfer xfer = {
+   .tx_buf = data,
+   .bits_per_word = 8,
+   .len = size
+   };
+
+   struct spi_message msg;
+   spi_message_init(&msg);
+   spi_message_add_tail(&xfer, &msg);
+
+   gpiod_set_value(ili->dc_gpio, 1);
+
+   return spi_sync(ili->spi, &msg);
+}
+
+#define ili9341_spi_write(ili, cmd, data...) \
+({ \
+   u8 d[] = { data }; \
+   ili9341_spi_write_command(ili, cmd); \
+ 

Re: [PATCH v2 2/5] drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.
On Wed, Feb 27, 2019 at 11:54:20PM +0200, Jyri Sarha wrote:
> Set output mode to HDMI or DVI according to EDID HDMI signature.
> 
> Signed-off-by: Jyri Sarha 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/sii902x.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index 1afa000141d5..0e21fa419d27 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -181,11 +181,15 @@ static int sii902x_get_modes(struct drm_connector 
> *connector)
>   struct sii902x *sii902x = connector_to_sii902x(connector);
>   u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>   struct edid *edid;
> + u8 output_mode = SII902X_SYS_CTRL_OUTPUT_DVI;

I'd move this one line up, but that's certainly a matter of taste :-)
>   int num = 0, ret;
>  
>   edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]);
>   drm_connector_update_edid_property(connector, edid);
>   if (edid) {
> + if (drm_detect_hdmi_monitor(edid))
> + output_mode = SII902X_SYS_CTRL_OUTPUT_HDMI;
> +
>   num = drm_add_edid_modes(connector, edid);
>   kfree(edid);
>   }
> @@ -195,6 +199,11 @@ static int sii902x_get_modes(struct drm_connector 
> *connector)
>   if (ret)
>   return ret;
>  
> + ret = regmap_update_bits(sii902x->regmap, SII902X_SYS_CTRL_DATA,
> +  SII902X_SYS_CTRL_OUTPUT_MODE, output_mode);
> + if (ret)
> + return ret;
> +

Is this the right place to update the register, shouldn't this be done
in sii902x_bridge_enable() instead ? I could foresee cases where the
chip could be powered down between get_modes() and enable(), losing its
internal state.

>   return num;
>  }
>  

-- 
Regards,

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

[Bug 202735] CONFIG_DRM_TTM does not have name in Kconfig, so it is invisble for menuconfig

[bugzilla-daemon]

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

--- Comment #3 from Jani Nikula (jani.nik...@intel.com) ---
Arguably not a bug in kernel.

-- 
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

Re: [PATCH v5 2/2] drm/lima: driver for ARM Mali4xx GPUs

[Qiang Yu]

Hi Sam,

Thanks, I'll fix them in next version.

Regards,
Qiang

On Sun, Mar 3, 2019 at 11:02 PM Sam Ravnborg  wrote:
>
> Hi Qiang.
>
> Good to see you do prompt follow-up on the feedback you get.
> I applied the patch and noticed that git compains about
> a few whitespace errors.
> So for good measure I throw checkpatch after it.
> $ scripts/checkpatch.pl --max-line-length=120 ~/lima
>
> ...
> total: 45 errors, 36 warnings, 4197 lines checked
>
> Several (most) of these looks like legitimate issues and should
> be fixed.
> It is much easier to do it now, rather than handle the trivial
> patches later.
>
> Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/17] drm/tegra: Convert to using __drm_atomic_helper_crtc_reset() for reset.

[Thierry Reding]

On Fri, Mar 01, 2019 at 01:56:24PM +0100, Maarten Lankhorst wrote:
> Convert tegra to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding destroy_state(),
> call it directly for freeing the old state.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: linux-te...@vger.kernel.org
> ---
>  drivers/gpu/drm/tegra/dc.c | 30 +++---
>  1 file changed, 11 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 607a6ea17ecc..57c88d78cdaa 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -1153,25 +1153,6 @@ static void tegra_dc_destroy(struct drm_crtc *crtc)
>   drm_crtc_cleanup(crtc);
>  }
>  
> -static void tegra_crtc_reset(struct drm_crtc *crtc)
> -{
> - struct tegra_dc_state *state;
> -
> - if (crtc->state)
> - __drm_atomic_helper_crtc_destroy_state(crtc->state);
> -
> - kfree(crtc->state);
> - crtc->state = NULL;
> -
> - state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = &state->base;
> - crtc->state->crtc = crtc;
> - }
> -
> - drm_crtc_vblank_reset(crtc);
> -}
> -
>  static struct drm_crtc_state *
>  tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
>  {
> @@ -1198,6 +1179,17 @@ static void tegra_crtc_atomic_destroy_state(struct 
> drm_crtc *crtc,
>   kfree(state);
>  }
>  
> +static void tegra_crtc_reset(struct drm_crtc *crtc)
> +{
> + struct tegra_dc_state *state = kzalloc(sizeof(*state), GFP_KERNEL);
> +
> + if (crtc->state)
> + tegra_crtc_atomic_destroy_state(crtc, crtc->state);
> +
> + __drm_atomic_helper_crtc_reset(crtc, &state->base);
> + drm_crtc_vblank_reset(crtc);
> +}
> +

I would preferred a predeclaration of tegra_crtc_atomic_destroy_state()
in this case because the implementations are in the same order as their
use in tegra_crtc_funcs, but I think I can live with it, so either way:

Acked-by: Thierry Reding 


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

Re: [linux-sunxi] [RESEND PATCH] drm/sun4i: hdmi: Improve compatibility with hpd-less HDMI displays

[Luc Verhaegen]

On Mon, Mar 04, 2019 at 03:06:16PM +0200, Priit Laes wrote:
> From: Priit Laes 
> 
> Even though HDMI connector features hotplug detect pin (HPD), there
> are older devices which do not support it. For these devices fall
> back to additional check on I2C bus to probe for EDID data.
> 
> One known example is HDMI/DVI display with following edid:
> 
> $ xxd -p display.edid
> 000005a1e0030100150f0103800f05780a0f6ea05748
> 9a2610474f20010101010101010101010101010101012a08804520e0
> 0b10200040009536001800fd0034441a2403000a202020202020
> 001000310a202020202020202020202000102a4030701300
> 782d111e006b
> 
> $ edid-decode display.edid
> EDID version: 1.3
> Manufacturer: AMA Model 3e0 Serial Number 1
> Digital display
> Maximum image size: 15 cm x 5 cm
> Gamma: 2.20
> RGB color display
> First detailed timing is preferred timing
> Display x,y Chromaticity:
>   Red:   0.6250, 0.3398
>   Green: 0.2841, 0.6044
>   Blue:  0.1494, 0.0644
>   White: 0.2802, 0.3105
> 
> Established timings supported:
>   640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz
> Standard timings supported:
> Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm
>640  672  672  709 hborder 0
>480  484  484  491 vborder 0
>-hsync -vsync
>VertFreq: 60 Hz, HorFreq: 29478 Hz
> Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz
> Dummy block
> Dummy block
> Checksum: 0x6b (valid)
> 
> Now, current implementation is still flawed, as HDMI uses the
> HPD signal to indicate that the source should re-read the EDID
> due to change in device capabilities. With current HPD polling
> implementation we would most certainly miss those notifications
> as one can try just swapping two HDMI monitors really fast.
> 
> Proper fix would be skipping the HPD pin detection and relying
> on just EDID fetching and acting on its changes.

HPD has been a hard requirement since DDWG came up with DVI somewhere in 
the late 90s. This monitor is plainly broken, and should not get an 
expensive i2c address polling based workaround at the driver level.

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

[Bug 202735] CONFIG_DRM_TTM does not have name in Kconfig, so it is invisble for menuconfig

[bugzilla-daemon]

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

--- Comment #4 from Ilya (kazakevichi...@gmail.com) ---
Not a bug at all. I'd call it "usability problem")

User can't enable TTM (which is required for virtualbox) unless she enables
some redundant driver.

-- 
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

Re: [PATCH 15/17] drm/vc4: Convert to using __drm_atomic_helper_crtc_reset() for reset.

[Maarten Lankhorst]

Op 01-03-2019 om 23:47 schreef Eric Anholt:
> Maarten Lankhorst  writes:
>
>> Convert vc4 to using __drm_atomic_helper_crtc_reset(), instead of
>> writing its own version. Instead of open coding destroy_state(),
>> call it directly for freeing the old state.
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Eric Anholt 
>> ---
>>  drivers/gpu/drm/vc4/vc4_crtc.c | 9 +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
>> index e7c04a9eb219..fdf21594b050 100644
>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
>> @@ -1041,12 +1041,13 @@ static void vc4_crtc_destroy_state(struct drm_crtc 
>> *crtc,
>>  static void
>>  vc4_crtc_reset(struct drm_crtc *crtc)
>>  {
>> -if (crtc->state)
>> -vc4_crtc_destroy_state(crtc->state);
>> +struct vc4_crtc_state *crtc_state =
>> +kzalloc(sizeof(*crtc_state), GFP_KERNEL);
>>  
>> -crtc->state = kzalloc(sizeof(struct vc4_crtc_state), GFP_KERNEL);
>>  if (crtc->state)
>> -crtc->state->crtc = crtc;
>> +vc4_crtc_destroy_state(crtc, crtc->state);
>> +
>> +__drm_atomic_helper_crtc_reset(crtc, &crtc_state->base);
> Wouldn't it be much easier if __drm_atomic_helper_crtc_reset took in a
> new state and destroyed the old state for you?  It seems like hardly a
> helper as is.

Yes it would, but the plane/connector reset is the same. If you want to convert 
them all it would be nice. :)

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

Re: [PATCH v2 2/5] drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID

[Jyri Sarha]

On 04/03/2019 14:52, Laurent Pinchart wrote:
> Hi Jyri,
> 
> Thank you for the patch.
> On Wed, Feb 27, 2019 at 11:54:20PM +0200, Jyri Sarha wrote:
>> Set output mode to HDMI or DVI according to EDID HDMI signature.
>>
>> Signed-off-by: Jyri Sarha 
>> Reviewed-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/bridge/sii902x.c | 9 +
>>  1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
>> b/drivers/gpu/drm/bridge/sii902x.c
>> index 1afa000141d5..0e21fa419d27 100644
>> --- a/drivers/gpu/drm/bridge/sii902x.c
>> +++ b/drivers/gpu/drm/bridge/sii902x.c
>> @@ -181,11 +181,15 @@ static int sii902x_get_modes(struct drm_connector 
>> *connector)
>>  struct sii902x *sii902x = connector_to_sii902x(connector);
>>  u32 bus_format = MEDIA_BUS_FMT_RGB888_1X24;
>>  struct edid *edid;
>> +u8 output_mode = SII902X_SYS_CTRL_OUTPUT_DVI;
> 
> I'd move this one line up, but that's certainly a matter of taste :-)

I usually sort the local variables by length too. I wonder why I did not
do it this time... I'll fix it :).

>>  int num = 0, ret;
>>  
>>  edid = drm_get_edid(connector, sii902x->i2cmux->adapter[0]);
>>  drm_connector_update_edid_property(connector, edid);
>>  if (edid) {
>> +if (drm_detect_hdmi_monitor(edid))
>> +output_mode = SII902X_SYS_CTRL_OUTPUT_HDMI;
>> +
>>  num = drm_add_edid_modes(connector, edid);
>>  kfree(edid);
>>  }
>> @@ -195,6 +199,11 @@ static int sii902x_get_modes(struct drm_connector 
>> *connector)
>>  if (ret)
>>  return ret;
>>  
>> +ret = regmap_update_bits(sii902x->regmap, SII902X_SYS_CTRL_DATA,
>> + SII902X_SYS_CTRL_OUTPUT_MODE, output_mode);
>> +if (ret)
>> +return ret;
>> +
> 
> Is this the right place to update the register, shouldn't this be done
> in sii902x_bridge_enable() instead ? I could foresee cases where the
> chip could be powered down between get_modes() and enable(), losing its
> internal state.
> 

I have a spec (unfortunately I can not share it) that describes the
sequence of handling a hot plug event on sii9022. There it is said that
the HDMI mode, if HDMI signature is found, should be set at the same
time while releasing the DCC access by setting SII902X_SYS_CTRL_DATA
bits #1 and #2 to zero.

However, I did not dare to change sii902x_i2c_bypass_deselect()
function, so I set the HDMI mode right after the DCC pass trough mode is
disabled.

Having it there is logical too, since the HDMI/DVI-mode should not
change without a hot plug event. In practice sii9022 does not appear to
be too picky when the bit is set.

>>  return num;
>>  }
>>  
> 


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm/bridge: sii902x: HDMI-audio support and some fixes

[Jyri Sarha]

On 04/03/2019 14:42, Laurent Pinchart wrote:
> Hi Jyri,
> 
> On Wed, Feb 27, 2019 at 11:54:18PM +0200, Jyri Sarha wrote:
>> Changes since first version:
>> - Moved reviewed patches to front:
>>   - drm/bridge: sii902x: add input_bus_flags
>>   - drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID
>>   - drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
>> - Added a new fix:
>>   - drm/bridge: sii902x: Select I2C_MUX
>> - Applied some review suggestions to
>>   - drm/bridge: sii902x: Implement HDMI audio support
>> - use clock-names property to name mclk
>> - move comment describing added mutex to struct sii902x and improve it
>> - cleanup sii902x_mute()
>> - cleanup sii902x_select_mclk_div()
>> - fix condition for checking ENABLE_BIT from i2s_fifo_routing in
>>   sii902x_audio_codec_init()
>>
>> Still to do
>>
>> - Agree on i2s wires to HDMI audio fifo routing in dts. 
>>
>>   The current scheme is quite straight forward, but there is maybe
>>   there is even more straight forward solutions like:
>>
>>   audio-fifo-enable = <1 1 1 1>;
>>   audio-i2s-pin-to-fifo = <0 1 2 3>;
>>
>>   Meaning that all fifos are enabled and SD0 is routed to fifo 0, SD1
>>   to fifo 1, etc. I am not sure if the channel swap functionality
>>   should show in dts binding.
> Please forgive my lack of audio knowledge, but it this a system
> description that should be encoded in DT, or a policy that should be
> handled purely in software (either fully inside the kernel or with the
> help of userspace) ?
> 

This property describes how many i2s wires are connected to sii902x and
in what order, so I think it belongs to DTS.

One might of course wonder why anybody would put the i2s wires to any
other order than 0 <-> 0, 1 <-> 1, 2 <-> 2, and 3 <-> 3, but then a
again I've seen weirder board designs.

Best regards,
Jyri


-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/7] drm/tinydrm: Remove tinydrm_device

[Noralf Trønnes]

Den 25.02.2019 15.42, skrev Noralf Trønnes:
> This patchset is part of the effort to remove tinydrm.ko. It removes
> struct tinydrm_device and tinydrm.h.
> 
> Only one change in this version and that is expanding the driver
> example.
> 
> The drm_dev_unplug() dependency series has been applied together with
> some patches from the previous version.
> 
> I've cc'ed intel-gfx so the Intel CI can verify the parent device ref
> patch.
> 
> Noralf.
> 
> Noralf Trønnes (7):
>   drm/drv: Hold ref on parent device during drm_device lifetime
>   drm: Add devm_drm_dev_init()
>   drm/drv: DOC: Add driver example code
>   drm/tinydrm/repaper: Drop using tinydrm_device
>   drm/tinydrm: Drop using tinydrm_device
>   drm/tinydrm: Remove tinydrm_device
>   drm/tinydrm: Use drm_dev_enter/exit()
> 

Series is applied to drm-misc-next, thanks for reviewing!

Noralf.

>  Documentation/driver-model/devres.txt |   3 +
>  Documentation/gpu/tinydrm.rst |  32 +---
>  Documentation/gpu/todo.rst|   4 -
>  drivers/gpu/drm/drm_drv.c | 176 +-
>  drivers/gpu/drm/tinydrm/core/Makefile |   2 +-
>  drivers/gpu/drm/tinydrm/core/tinydrm-core.c   | 169 -
>  .../gpu/drm/tinydrm/core/tinydrm-helpers.c|   2 +
>  drivers/gpu/drm/tinydrm/hx8357d.c |  49 -
>  drivers/gpu/drm/tinydrm/ili9225.c |  63 ++-
>  drivers/gpu/drm/tinydrm/ili9341.c |  49 -
>  drivers/gpu/drm/tinydrm/mi0283qt.c|  49 -
>  drivers/gpu/drm/tinydrm/mipi-dbi.c| 109 ---
>  drivers/gpu/drm/tinydrm/repaper.c | 130 +
>  drivers/gpu/drm/tinydrm/st7586.c  | 129 -
>  drivers/gpu/drm/tinydrm/st7735r.c |  49 -
>  include/drm/drm_drv.h |   3 +
>  include/drm/tinydrm/mipi-dbi.h|  26 ++-
>  include/drm/tinydrm/tinydrm.h |  42 -
>  18 files changed, 688 insertions(+), 398 deletions(-)
>  delete mode 100644 drivers/gpu/drm/tinydrm/core/tinydrm-core.c
>  delete mode 100644 include/drm/tinydrm/tinydrm.h
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] tinydrm/mipi-dbi: Use dma-safe buffers for all SPI transfers

[Noralf Trønnes]

Den 22.02.2019 16.58, skrev Andy Shevchenko:
> On Fri, Feb 22, 2019 at 01:43:29PM +0100, Noralf Trønnes wrote:
>> Buffers passed to spi_sync() must be dma-safe even for tiny buffers since
>> some SPI controllers use DMA for all transfers.
>>
>> Example splat with CONFIG_DMA_API_DEBUG enabled:
>>
>> [   23.750467] DMA-API: dw_dmac_pci :00:15.0: device driver maps memory 
>> from stack [probable addr=1e49185d]
>> [   23.750529] WARNING: CPU: 1 PID: 1296 at kernel/dma/debug.c:1161 
>> check_for_stack+0xb7/0x190
>> [   23.750533] Modules linked in: mmc_block(+) spi_pxa2xx_platform(+) 
>> pwm_lpss_pci pwm_lpss spi_pxa2xx_pci sdhci_pci cqhci intel_mrfld_pwrbtn 
>> extcon_intel_mrfld sdhci intel_mrfld_adc led_class mmc_core ili9341 mipi_dbi 
>> tinydrm backlight ti_ads7950 industrialio_triggered_buffer kfifo_buf 
>> intel_soc_pmic_mrfld hci_uart btbcm
>> [   23.750599] CPU: 1 PID: 1296 Comm: modprobe Not tainted 5.0.0-rc7+ #236
>> [   23.750605] Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 
>> 542 2015.01.21:18.19.48
>> [   23.750620] RIP: 0010:check_for_stack+0xb7/0x190
>> [   23.750630] Code: 8b 6d 50 4d 85 ed 75 04 4c 8b 6d 10 48 89 ef e8 2f 8b 
>> 44 00 48 89 c6 4a 8d 0c 23 4c 89 ea 48 c7 c7 88 d0 82 b4 e8 40 7c f9 ff <0f> 
>> 0b 8b 05 79 00 4b 01 85 c0 74 07 5b 5d 41 5c 41 5d c3 8b 05 54
>> [   23.750637] RSP: :97bbc0292fa0 EFLAGS: 00010286
>> [   23.750646] RAX:  RBX: 97bbc029 RCX: 
>> 0006
>> [   23.750652] RDX: 0007 RSI: 0002 RDI: 
>> 94b33e115450
>> [   23.750658] RBP: 94b33c8578b0 R08: 0002 R09: 
>> 000201c0
>> [   23.750664] R10: 0006ecb0ccc6 R11: 00034f38 R12: 
>> 316c
>> [   23.750670] R13: 94b33c84b250 R14: 94b33dedd5a0 R15: 
>> 0001
>> [   23.750679] FS:  () GS:94b33e10(0063) 
>> knlGS:f7faf690
>> [   23.750686] CS:  0010 DS: 002b ES: 002b CR0: 80050033
>> [   23.750691] CR2: f7f54faf CR3: 0722c000 CR4: 
>> 001006e0
>> [   23.750696] Call Trace:
>> [   23.750713]  debug_dma_map_sg+0x100/0x340
>> [   23.750727]  ? dma_direct_map_sg+0x3b/0xb0
>> [   23.750739]  spi_map_buf+0x25a/0x300
>> [   23.750751]  __spi_pump_messages+0x2a4/0x680
>> [   23.750762]  __spi_sync+0x1dd/0x1f0
>> [   23.750773]  spi_sync+0x26/0x40
>> [   23.750790]  mipi_dbi_typec3_command_read+0x14d/0x240 [mipi_dbi]
>> [   23.750802]  ? spi_finalize_current_transfer+0x10/0x10
>> [   23.750821]  mipi_dbi_typec3_command+0x1bc/0x1d0 [mipi_dbi]
>>
> 
> After few runs I don't see the warning anymore. So,
> Tested-by: Andy Shevchenko 
> 

Can I have an ack as well if you're satisfied with it?

Noralf.

> Though I would like to give few more days to monitor the state.
> (I believe it's fixed)
> 
>> Reported-by: Andy Shevchenko 
>> Signed-off-by: Noralf Trønnes 
>> ---
>>  drivers/gpu/drm/tinydrm/ili9225.c  |  6 ++--
>>  drivers/gpu/drm/tinydrm/mipi-dbi.c | 58 +-
>>  include/drm/tinydrm/mipi-dbi.h |  5 +--
>>  3 files changed, 48 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
>> b/drivers/gpu/drm/tinydrm/ili9225.c
>> index 3f59cfbd31ba..a87078667e04 100644
>> --- a/drivers/gpu/drm/tinydrm/ili9225.c
>> +++ b/drivers/gpu/drm/tinydrm/ili9225.c
>> @@ -299,7 +299,7 @@ static void ili9225_pipe_disable(struct 
>> drm_simple_display_pipe *pipe)
>>  mipi->enabled = false;
>>  }
>>  
>> -static int ili9225_dbi_command(struct mipi_dbi *mipi, u8 cmd, u8 *par,
>> +static int ili9225_dbi_command(struct mipi_dbi *mipi, u8 *cmd, u8 *par,
>> size_t num)
>>  {
>>  struct spi_device *spi = mipi->spi;
>> @@ -309,11 +309,11 @@ static int ili9225_dbi_command(struct mipi_dbi *mipi, 
>> u8 cmd, u8 *par,
>>  
>>  gpiod_set_value_cansleep(mipi->dc, 0);
>>  speed_hz = mipi_dbi_spi_cmd_max_speed(spi, 1);
>> -ret = tinydrm_spi_transfer(spi, speed_hz, NULL, 8, &cmd, 1);
>> +ret = tinydrm_spi_transfer(spi, speed_hz, NULL, 8, cmd, 1);
>>  if (ret || !num)
>>  return ret;
>>  
>> -if (cmd == ILI9225_WRITE_DATA_TO_GRAM && !mipi->swap_bytes)
>> +if (*cmd == ILI9225_WRITE_DATA_TO_GRAM && !mipi->swap_bytes)
>>  bpw = 16;
>>  
>>  gpiod_set_value_cansleep(mipi->dc, 1);
>> diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
>> b/drivers/gpu/drm/tinydrm/mipi-dbi.c
>> index 246e708a9ff7..4a4cd7e72938 100644
>> --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
>> +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
>> @@ -153,16 +153,42 @@ EXPORT_SYMBOL(mipi_dbi_command_read);
>>   */
>>  int mipi_dbi_command_buf(struct mipi_dbi *mipi, u8 cmd, u8 *data, size_t 
>> len)
>>  {
>> +u8 *cmdbuf;
>>  int ret;
>>  
>> +/* SPI requires dma-safe buffers */
>> +cmdbuf = kmemdup(&cmd, 1, GFP_KERNEL);
>> +if (!cmdbuf)
>> +return -ENOMEM;
>> +
>>  mutex_lock(&mipi->cmdlock);
>> -ret = mi

[PATCH 2/5] drm/rockchip: fix fb references in async update

[Helen Koike]

In the case of async update, modifications are done in place, i.e. in the
current plane state, so the new_state is prepared and the new_state is
cleanup up (instead of the old_state, diferrently on what happen in a
normal sync update).
To cleanup the old_fb properly, it needs to be placed in the new_state
in the end of async_update, so cleanup call will unreference the old_fb
correctly.

Also, the previous code had a:

plane_state = plane->funcs->atomic_duplicate_state(plane);
...
swap(plane_state, plane->state);

if (plane->state->fb && plane->state->fb != new_state->fb) {
...
}

Which was wrong, as the fb were just assigned to be equal, so this if
statement nevers evaluates to true.

Another details is that the function drm_crtc_vblank_get() can only be
called when vop->is_enabled is true, otherwise it has no effect and
trows a WARN_ON().

Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
fb and pus the old fb) is not required, as it is taken care by
drm_mode_cursor_universal() when calling
drm_atomic_helper_update_plane().

Signed-off-by: Helen Koike 

---
Hello,

I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.

It was me who worked on the first version and I am really sorry about that
dead code in the if statement.
Now I understand drm better and I know better how to properly test things with
more care/details.

Also, I didn't CC to stable here as I saw the async_update function was only
added on v4.20, please let me know if I should CC to stable.

Thanks!
Helen

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7d4c6073ea5..a1ee8c156a7b 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct 
drm_plane *plane,
  struct drm_plane_state *new_state)
 {
struct vop *vop = to_vop(plane->state->crtc);
-   struct drm_plane_state *plane_state;
+   struct drm_framebuffer *old_fb = plane->state->fb;
 
-   plane_state = plane->funcs->atomic_duplicate_state(plane);
-   plane_state->crtc_x = new_state->crtc_x;
-   plane_state->crtc_y = new_state->crtc_y;
-   plane_state->crtc_h = new_state->crtc_h;
-   plane_state->crtc_w = new_state->crtc_w;
-   plane_state->src_x = new_state->src_x;
-   plane_state->src_y = new_state->src_y;
-   plane_state->src_h = new_state->src_h;
-   plane_state->src_w = new_state->src_w;
-
-   if (plane_state->fb != new_state->fb)
-   drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
-
-   swap(plane_state, plane->state);
-
-   if (plane->state->fb && plane->state->fb != new_state->fb) {
+   /*
+* A scanout can still be occurring, so we can't drop the reference to
+* the old framebuffer. To solve this we get a reference to old_fb and
+* set a worker to release it later.
+*/
+   if (vop->is_enabled &&
+   plane->state->fb && plane->state->fb != new_state->fb) {
drm_framebuffer_get(plane->state->fb);
WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
drm_flip_work_queue(&vop->fb_unref_work, plane->state->fb);
set_bit(VOP_PENDING_FB_UNREF, &vop->pending);
}
 
+   plane->state->crtc_x = new_state->crtc_x;
+   plane->state->crtc_y = new_state->crtc_y;
+   plane->state->crtc_h = new_state->crtc_h;
+   plane->state->crtc_w = new_state->crtc_w;
+   plane->state->src_x = new_state->src_x;
+   plane->state->src_y = new_state->src_y;
+   plane->state->src_h = new_state->src_h;
+   plane->state->src_w = new_state->src_w;
+   plane->state->fb = new_state->fb;
+
if (vop->is_enabled) {
rockchip_drm_psr_inhibit_get_state(new_state->state);
vop_plane_atomic_update(plane, plane->state);
@@ -945,7 +946,12 @@ static void vop_plane_atomic_async_update(struct drm_plane 
*plane,
rockchip_drm_psr_inhibit_put_state(new_state->state);
}
 
-   plane->funcs->atomic_destroy_state(plane, plane_state);
+   /*
+* In async update we perform inplace modifications and release the
+* new_state. The following is required so we release the reference of
+* the old framebuffer.
+*/
+   new_state->fb = old_fb;
 }
 
 static const struct drm_plane_helper_funcs plane_helper_funcs = {
-- 
2.20.1

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

[PATCH 1/5] drm: don't block fb changes for async plane updates

[Helen Koike]

In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.

In the case of async updates, the preparation is also done in the
new_state but the cleanups are done in the new_state (because updates
are performed in place, i.e. in the current state).

The current code blocks async udpates when the fb is changed, turning
async updates into sync updates, slowing down cursor updates and
introducing regressions in igt tests with errors of type:

"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
expect to complete approximately 15360 updates, with the threshold set
at 7680"

Fb changes in async updates were prevented to avoid the following scenario:

- Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
Where we have a single call to prepare fb2 but double cleanup call to fb2.

To solve the above problems, instead of blocking async fb changes, we
place the old framebuffer in the new_state object, so when the code
performs cleanups in the new_state it will cleanup the old_fb and we
will have the following scenario instead:

- Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
- Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
- Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2

Where calls to prepare/cleanup are ballanced.

Cc:  # v4.14+: 25dc194b34dd: drm: Block fb changes for 
async plane updates
Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 

---
Hello,

As mentioned in the cover letter,
I tested on the rockchip and on i915 (with a patch I am still working on for
replacing cursors by async update), with igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.
I couldn't test on MSM and AMD because I don't have the hardware (and I am
having some issues testing on vc4) and I would appreciate if anyone could help
me testing those.

I also think it would be a better solution if, instead of having async
to do in-place updates in the current state, the async path should be
equivalent to a syncronous update, i.e., modifying new_state and
performing a flip
IMHO, the only difference between sync and async should be that async update
doesn't wait for vblank and applies the changes immeditally to the hw,
but the code path could be almost the same.
But for now I think this solution is ok (swaping new_fb/old_fb), and
then we can adjust things little by little, what do you think?

Thanks!
Helen

 drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 540a77a2ade9..e7eb96f1efc2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device *dev,
old_plane_state->crtc != new_plane_state->crtc)
return -EINVAL;
 
-   /*
-* FIXME: Since prepare_fb and cleanup_fb are always called on
-* the new_plane_state for async updates we need to block framebuffer
-* changes. This prevents use of a fb that's been cleaned up and
-* double cleanups from occuring.
-*/
-   if (old_plane_state->fb != new_plane_state->fb)
-   return -EINVAL;
-
funcs = plane->helper_private;
if (!funcs->atomic_async_update)
return -EINVAL;
@@ -1657,6 +1648,9 @@ void drm_atomic_helper_async_commit(struct drm_device 
*dev,
int i;
 
for_each_new_plane_in_state(state, plane, plane_state, i) {
+   struct drm_framebuffer *new_fb = plane_state->fb;
+   struct drm_framebuffer *old_fb = plane->state->fb;
+
funcs = plane->helper_private;
funcs->atomic_async_update(plane, plane_state);
 
@@ -1665,11 +1659,17 @@ void drm_atomic_helper_async_commit(struct drm_device 
*dev,
 * plane->state in-place, make sure at least common
 * properties have been properly updated.
 */
-   WARN_ON_ONCE(plane->state->fb != plane_state->fb);
+   WARN_ON_ONCE(plane->state->fb != new_fb);
WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
WARN_ON_ONCE(plane->state->src_x != plane_state->src_x);
WARN_ON_ONCE(plane->state->src_y != plane_state->src_y);
+
+   /*
+* Make sure the FBs have been swapped so that cleanups in t

[PATCH 0/5] drm: Fix fb changes for async updates

[Helen Koike]

Hello,

This series is a first attempt to fix the slow down in performance introduced by
"[PATCH v2] drm: Block fb changes for async plane updates" where async update
falls back to a sync update, causing igt failures of type:

"CRITICAL: completed 97 cursor updated in a period of 30 flips, we
expect to complete approximately 15360 updates, with the threshold set
at 7680"

Please read the commit message of the first patch to understand how it works.

I tested on the rockchip and on i915 (with a patch I am still working on for
replacing cursors by async update), with igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.
I couldn't test on MSM and AMD because I don't have the hardware and my vc4
raspberry pi is not recognizing my display for some reason, I would appreciate
if anyone could help me testing those.
I also separated the patches per platform to be easier to get the tested-by 
tags,
please let me know if it should be a single patch.

Also, I added CC stable (as the "drm: Block fb changes for async plane updates"
was also CCed to stable).
I am not used to CC stable, please let me know if anything is off.

Thanks!
Helen


Helen Koike (5):
  drm: don't block fb changes for async plane updates
  drm/rockchip: fix fb references in async update
  drm/amd: fix fb references in async update
  drm/msm: fix fb references in async update
  drm/vc4: fix fb references in async update

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +-
 drivers/gpu/drm/drm_atomic_helper.c   | 20 -
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c|  4 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 42 +++
 drivers/gpu/drm/vc4/vc4_plane.c   |  2 +-
 5 files changed, 40 insertions(+), 31 deletions(-)

-- 
2.20.1

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

[PATCH 3/5] drm/amd: fix fb references in async update

[Helen Koike]

Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.

Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().

Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 

---
Hello,

As mentioned in the cover letter,
I tested on the rockchip and on i915 using igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.
But I couldn't test on AMD because I don't have the hardware and I would
appreciate if anyone could test it.

Also, I didn't CC to stable here as I saw the async_update function was only
added on v4.20, please let me know if I should CC to stable.

Thanks!
Helen

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

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3a6f595f295e..bc02800254bf 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3760,8 +3760,7 @@ static void dm_plane_atomic_async_update(struct drm_plane 
*plane,
struct drm_plane_state *old_state =
drm_atomic_get_old_plane_state(new_state->state, plane);
 
-   if (plane->state->fb != new_state->fb)
-   drm_atomic_set_fb_for_plane(plane->state, new_state->fb);
+   swap(plane->state->fb, new_state->fb);
 
plane->state->src_x = new_state->src_x;
plane->state->src_y = new_state->src_y;
-- 
2.20.1

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

[PATCH 5/5] drm/vc4: fix fb references in async update

[Helen Koike]

Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.

Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().

Cc:  # v4.19+: 25dc194b34dd: drm: Block fb changes for 
async plane updates
Cc:  # v4.19+: 8105bbaf9afd: drm: don't block fb 
changes for async plane updates
Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 

---
Hello,

As mentioned in the cover letter,
I tested on the rockchip and on i915 using igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.
But I couldn't test on VC4. I have a Raspberry pi model B rev2, when
FB_SIMPLE is running I can see output on the screen, but when vc4 is
loaded my hdmi display is not detected anymore, I am still debugging
this, probably some config in the firmware, but I would appreciate if
anyone could help me testing it.

Also the Cc statble commit hash dependency needs to be updated once the
refered commit is merged.

Thanks!
Helen

 drivers/gpu/drm/vc4/vc4_plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 1babfeca0c92..1235e53b22a3 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -968,7 +968,7 @@ static void vc4_plane_atomic_async_update(struct drm_plane 
*plane,
 {
struct vc4_plane_state *vc4_state, *new_vc4_state;
 
-   drm_atomic_set_fb_for_plane(plane->state, state->fb);
+   swap(plane->state->fb, state->fb);
plane->state->crtc_x = state->crtc_x;
plane->state->crtc_y = state->crtc_y;
plane->state->crtc_w = state->crtc_w;
-- 
2.20.1

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

[PATCH 4/5] drm/msm: fix fb references in async update

[Helen Koike]

Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.

Cc:  # v4.14+: 25dc194b34dd: drm: Block fb changes for 
async plane updates
Cc:  # v4.14+: 8105bbaf9afd: drm: don't block fb 
changes for async plane updates
Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
Suggested-by: Boris Brezillon 
Signed-off-by: Helen Koike 

---
Hello,

As mentioned in the cover letter,
I tested on the rockchip and on i915 using igt plane_cursor_legacy and
kms_cursor_legacy and I didn't see any regressions.
But I couldn't test on MSM because I don't have the hardware and I would
appreciate if anyone could test it.

In other platforms (VC4, AMD, Rockchip), there is a hidden
drm_framebuffer_get(new_fb)/drm_framebuffer_put(old_fb) in async_update
that is wrong, but I couldn't identify those here, not sure if it is hidden
somewhere else, but if tests fail this is probably the cause.

Thanks!
Helen

 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index be13140967b4..b854f471e9e5 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -502,6 +502,8 @@ static int mdp5_plane_atomic_async_check(struct drm_plane 
*plane,
 static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
   struct drm_plane_state *new_state)
 {
+   struct drm_framebuffer *old_fb = plane->state->fb;
+
plane->state->src_x = new_state->src_x;
plane->state->src_y = new_state->src_y;
plane->state->crtc_x = new_state->crtc_x;
@@ -524,6 +526,8 @@ static void mdp5_plane_atomic_async_update(struct drm_plane 
*plane,
 
*to_mdp5_plane_state(plane->state) =
*to_mdp5_plane_state(new_state);
+
+   new_state->fb = old_fb;
 }
 
 static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
-- 
2.20.1

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

[PATCH 0/7] drm/vc4: Allow for more boot-time configuration

[Maxime Ripard]

Hi,

The proprietary stack for the RaspberryPi allows for a number of video
parameters widely used by their users, but yet don't have any equivalents
in the mainline kernel.

Those options are detailed here:
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

While not all of them are desirable to have in the mainline kernel, some of
them still have value, such as properties to initialise the overscan or
rotation parameters, or the one to deal with broken displays.

This series is an attempt to support those, and is based on a rewrite of
the command line parser I did a couple of years ago that never reached
upstream (due to a lack of time on my side). While this parser was
initially made to deal with named modes (in order to support TV modes), it
also allowed to extend it more easily, which is why it's resurrected.

Since a change of the command line parser can pretty easily get things
wrong and introduce regressions, I also worked with a number of unit tests
that you can find here: http://code.bulix.org/tpo7dg-607264?raw

Eventually, I guess those tests should be part of the kernel somewhere, but
I haven't found a suitable place for them to be included yet.

Let me know what you think,
Maxime

Maxime Ripard (7):
  drm/vc4: hdmi: Check that the monitor supports HDMI audio
  drm/edid: Allow to ignore the audio EDID data
  drm/edid: Allow to ignore the HDMI monitor mode
  drm/modes: Rewrite the command line parser
  drm/modes: Support modes names on the command line
  drm/modes: Allow to specify rotation and reflection on the commandline
  drm/modes: Parse overscan properties

 drivers/gpu/drm/drm_connector.c |   3 +-
 drivers/gpu/drm/drm_edid.c  |  16 +-
 drivers/gpu/drm/drm_fb_helper.c |  55 -
 drivers/gpu/drm/drm_modes.c | 441 -
 drivers/gpu/drm/vc4/vc4_hdmi.c  |   6 +-
 include/drm/drm_connector.h |   3 +-
 6 files changed, 408 insertions(+), 116 deletions(-)

base-commit: e179d8e074e05a913a0915ae3c4b82f1434d9f4e
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/7] drm/vc4: hdmi: Check that the monitor supports HDMI audio

[Maxime Ripard]

The current code assumes as soon as the device is an HDMI one that it
supports an audio sink. However, strictly speaking, this is exposed as a
separate part of EDID.

This can be checked through the drm_detect_monitor_audio function, so let's
use it and make sure that we can use the HDMI monitor as an output before
sending sound.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 88fd5df7e7dc..a1bdc065c47c 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -109,6 +109,7 @@ struct vc4_hdmi_encoder {
struct vc4_encoder base;
bool hdmi_monitor;
bool limited_rgb_range;
+   bool monitor_has_audio;
 };
 
 static inline struct vc4_hdmi_encoder *
@@ -278,6 +279,7 @@ static int vc4_hdmi_connector_get_modes(struct 
drm_connector *connector)
return -ENODEV;
 
vc4_encoder->hdmi_monitor = drm_detect_hdmi_monitor(edid);
+   vc4_encoder->monitor_has_audio = drm_detect_monitor_audio(edid);
 
drm_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
@@ -785,9 +787,13 @@ static int vc4_hdmi_audio_startup(struct snd_pcm_substream 
*substream,
 {
struct vc4_hdmi *hdmi = dai_to_hdmi(dai);
struct drm_encoder *encoder = hdmi->encoder;
+   struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
struct vc4_dev *vc4 = to_vc4_dev(encoder->dev);
int ret;
 
+   if (!vc4_encoder->monitor_has_audio)
+   return -ENODEV;
+
if (hdmi->audio.substream && hdmi->audio.substream != substream)
return -EINVAL;
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/7] drm/modes: Rewrite the command line parser

[Maxime Ripard]

From: Maxime Ripard 

Rewrite the command line parser in order to get away from the state machine
parsing the video mode lines.

Hopefully, this will allow to extend it more easily to support named modes
and / or properties set directly on the command line.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_modes.c | 308 +++--
 1 file changed, 193 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 869ac6f4671e..31d61940c007 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -30,6 +30,7 @@
  * authorization from the copyright holder(s) and author(s).
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -1405,6 +1406,131 @@ void drm_connector_list_update(struct drm_connector 
*connector)
 }
 EXPORT_SYMBOL(drm_connector_list_update);
 
+static int drm_mode_parse_cmdline_bpp(const char *str, char **end_ptr,
+ struct drm_cmdline_mode *mode)
+{
+   if (str[0] != '-')
+   return -EINVAL;
+
+   mode->bpp = simple_strtol(str + 1, end_ptr, 10);
+   mode->bpp_specified = true;
+
+   return 0;
+}
+
+static int drm_mode_parse_cmdline_refresh(const char *str, char **end_ptr,
+ struct drm_cmdline_mode *mode)
+{
+   if (str[0] != '@')
+   return -EINVAL;
+
+   mode->refresh = simple_strtol(str + 1, end_ptr, 10);
+   mode->refresh_specified = true;
+
+   return 0;
+}
+
+static int drm_mode_parse_cmdline_extra(const char *str, int length,
+   struct drm_connector *connector,
+   struct drm_cmdline_mode *mode)
+{
+   int i;
+
+   for (i = 0; i < length; i++) {
+   switch (str[i]) {
+   case 'i':
+   mode->interlace = true;
+   break;
+   case 'm':
+   mode->margins = true;
+   break;
+   case 'D':
+   if (mode->force != DRM_FORCE_UNSPECIFIED)
+   return -EINVAL;
+
+   if ((connector->connector_type != 
DRM_MODE_CONNECTOR_DVII) &&
+   (connector->connector_type != 
DRM_MODE_CONNECTOR_HDMIB))
+   mode->force = DRM_FORCE_ON;
+   else
+   mode->force = DRM_FORCE_ON_DIGITAL;
+   break;
+   case 'd':
+   if (mode->force != DRM_FORCE_UNSPECIFIED)
+   return -EINVAL;
+
+   mode->force = DRM_FORCE_OFF;
+   break;
+   case 'e':
+   if (mode->force != DRM_FORCE_UNSPECIFIED)
+   return -EINVAL;
+
+   mode->force = DRM_FORCE_ON;
+   break;
+   default:
+   return -EINVAL;
+   }
+   }
+
+   return 0;
+}
+
+static int drm_mode_parse_cmdline_res_mode(const char *str, unsigned int 
length,
+  bool extras,
+  struct drm_connector *connector,
+  struct drm_cmdline_mode *mode)
+{
+   bool rb = false, cvt = false;
+   int xres = 0, yres = 0;
+   int remaining, i;
+   char *end_ptr;
+
+   xres = simple_strtol(str, &end_ptr, 10);
+
+   if (end_ptr[0] != 'x')
+   return -EINVAL;
+   end_ptr++;
+
+   yres = simple_strtol(end_ptr, &end_ptr, 10);
+
+   remaining = length - (end_ptr - str);
+   if (remaining < 0)
+   return -EINVAL;
+
+   for (i = 0; i < remaining; i++) {
+   switch (end_ptr[i]) {
+   case 'M':
+   cvt = true;
+   break;
+   case 'R':
+   rb = true;
+   break;
+   default:
+   /*
+* Try to pass that to our extras parsing
+* function to handle the case where the
+* extras are directly after the resolution
+*/
+   if (extras) {
+   int ret = drm_mode_parse_cmdline_extra(end_ptr 
+ i,
+  1,
+  
connector,
+  mode);
+   if (ret)
+   return ret;
+   } else {
+   return -EINVAL;
+   }
+   }
+   }
+
+   mode->xres = xres;
+   mode->

[PATCH 5/7] drm/modes: Support modes names on the command line

[Maxime Ripard]

From: Maxime Ripard 

The drm subsystem also uses the video= kernel parameter, and in the
documentation refers to the fbdev documentation for that parameter.

However, that documentation also says that instead of giving the mode using
its resolution we can also give a name. However, DRM doesn't handle that
case at the moment. Even though in most case it shouldn't make any
difference, it might be useful for analog modes, where different standards
might have the same resolution, but still have a few different parameters
that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example).

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_connector.c |  3 +-
 drivers/gpu/drm/drm_fb_helper.c |  4 +++-
 drivers/gpu/drm/drm_modes.c | 49 +++---
 include/drm/drm_connector.h |  1 +-
 4 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dd40eff0911c..799e932c114d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -139,8 +139,9 @@ static void drm_connector_get_cmdline_mode(struct 
drm_connector *connector)
connector->force = mode->force;
}
 
-   DRM_DEBUG_KMS("cmdline mode for connector %s %dx%d@%dHz%s%s%s\n",
+   DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n",
  connector->name,
+ mode->name ? mode->name : "",
  mode->xres, mode->yres,
  mode->refresh_specified ? mode->refresh : 60,
  mode->rb ? " reduced blanking" : "",
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0e9349ff2d16..cacc4b56344e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2158,6 +2158,10 @@ struct drm_display_mode *drm_pick_cmdline_mode(struct 
drm_fb_helper_connector *f
prefer_non_interlace = !cmdline_mode->interlace;
 again:
list_for_each_entry(mode, &fb_helper_conn->connector->modes, head) {
+   /* Check (optional) mode name first */
+   if (!strcmp(mode->name, cmdline_mode->name))
+   return mode;
+
/* check width/height */
if (mode->hdisplay != cmdline_mode->xres ||
mode->vdisplay != cmdline_mode->yres)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 31d61940c007..3d843d17370a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1557,7 +1557,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
   struct drm_cmdline_mode *mode)
 {
const char *name;
-   bool parse_extras = false;
+   bool named_mode = false, parse_extras = false;
unsigned int bpp_off = 0, refresh_off = 0;
unsigned int mode_end = 0;
char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
@@ -1576,8 +1576,14 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 
name = mode_option;
 
+   /*
+* If the first character is not a digit, then it means that
+* we have a named mode.
+*/
if (!isdigit(name[0]))
-   return false;
+   named_mode = true;
+   else
+   named_mode = false;
 
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strchr(name, '-');
@@ -1607,12 +1613,16 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
parse_extras = true;
}
 
-   ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
- parse_extras,
- connector,
- mode);
-   if (ret)
-   return false;
+   if (named_mode) {
+   strncpy(mode->name, name, mode_end);
+   } else {
+   ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
+ parse_extras,
+ connector,
+ mode);
+   if (ret)
+   return false;
+   }
mode->specified = true;
 
if (bpp_ptr) {
@@ -1640,14 +1650,23 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
extra_ptr = refresh_end_ptr;
 
if (extra_ptr) {
-   int remaining = strlen(name) - (extra_ptr - name);
+   if (!named_mode) {
+   int len = strlen(name) - (extra_ptr - name);
 
-   /*
-* We still have characters to process, while
-* we shouldn't have any
-*/
-   if (remaining > 0)
-   retu

[PATCH 2/7] drm/edid: Allow to ignore the audio EDID data

[Maxime Ripard]

In some cases, in order to accomodate with displays with poor EDIDs, we
need to ignore that the monitor alledgedly supports audio output and
disable the audio output.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_edid.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b1909f9d7..c0258b011bb2 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
 }
 EXPORT_SYMBOL(drm_detect_hdmi_monitor);
 
+static bool ignore_edid_audio = false;
+module_param(ignore_edid_audio, bool, 0644);
+MODULE_PARM_DESC(ignore_edid_audio,
+"Ignore the EDID and always consider that a monitor doesn't 
have audio capabilities");
+
 /**
  * drm_detect_monitor_audio - check monitor audio capability
  * @edid: EDID block to scan
@@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *edid)
bool has_audio = false;
int start_offset, end_offset;
 
+   if (ignore_edid_audio)
+   goto end;
+
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
goto end;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/7] drm/modes: Parse overscan properties

[Maxime Ripard]

Properly configuring the overscan properties might be needed for the
initial setup of the framebuffer for display that still have overscan.
Let's allow for more properties on the kernel command line to setup each
margin.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_fb_helper.c | 47 ++-
 drivers/gpu/drm/drm_modes.c | 44 -
 include/drm/drm_connector.h |  1 +-
 3 files changed, 92 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1457a1d1a423..3569016111a4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2569,6 +2569,51 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper 
*fb_helper,
fb_helper->sw_rotations |= DRM_MODE_ROTATE_0;
 }
 
+static void drm_setup_connector_margins(struct drm_connector *connector)
+{
+   struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
+   struct drm_modeset_acquire_ctx ctx;
+   struct drm_atomic_state *state;
+   struct drm_device *dev = connector->dev;
+   int ret;
+
+   if (!drm_drv_uses_atomic_modeset(dev))
+   return;
+
+   drm_modeset_acquire_init(&ctx, 0);
+
+   state = drm_atomic_state_alloc(dev);
+   state->acquire_ctx = &ctx;
+
+retry:
+   drm_atomic_set_property(state, &connector->base,
+   dev->mode_config.tv_left_margin_property,
+   cmdline->overscan_left);
+
+   drm_atomic_set_property(state, &connector->base,
+   dev->mode_config.tv_right_margin_property,
+   cmdline->overscan_right);
+
+   drm_atomic_set_property(state, &connector->base,
+   dev->mode_config.tv_top_margin_property,
+   cmdline->overscan_top);
+
+   drm_atomic_set_property(state, &connector->base,
+   dev->mode_config.tv_bottom_margin_property,
+   cmdline->overscan_bottom);
+
+   ret = drm_atomic_commit(state);
+   if (ret == -EDEADLK) {
+   drm_atomic_state_clear(state);
+   drm_modeset_backoff(&ctx);
+   goto retry;
+   }
+
+   drm_atomic_state_put(state);
+   drm_modeset_drop_locks(&ctx);
+   drm_modeset_acquire_fini(&ctx);
+}
+
 static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
u32 width, u32 height)
 {
@@ -2682,6 +2727,8 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper 
*fb_helper)
struct drm_connector *connector =
fb_helper->connector_info[i]->connector;
 
+   drm_setup_connector_margins(connector);
+
/* use first connected connector for the physical dimensions */
if (connector->status == connector_status_connected) {
info->var.width = connector->display_info.width_mm;
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 10c7e9322f76..6613db04cf77 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1586,6 +1586,50 @@ static int drm_mode_parse_cmdline_options(char *str, 
size_t len,
} else if (!strncmp(option, "reflect_y", delim - option)) {
rotation |= DRM_MODE_REFLECT_Y;
sep = delim;
+   } else if (!strncmp(option, "overscan_right", delim - option)) {
+   const char *value = delim + 1;
+   unsigned int margin;
+
+   margin = simple_strtol(value, &sep, 10);
+
+   /* Make sure we have parsed something */
+   if (sep == value)
+   return -EINVAL;
+
+   mode->overscan_right = margin;
+   } else if (!strncmp(option, "overscan_left", delim - option)) {
+   const char *value = delim + 1;
+   unsigned int margin;
+
+   margin = simple_strtol(value, &sep, 10);
+
+   /* Make sure we have parsed something */
+   if (sep == value)
+   return -EINVAL;
+
+   mode->overscan_left = margin;
+   } else if (!strncmp(option, "overscan_top", delim - option)) {
+   const char *value = delim + 1;
+   unsigned int margin;
+
+   margin = simple_strtol(value, &sep, 10);
+
+   /* Make sure we have parsed something */
+   if (sep == value)
+   return -EINVAL;
+
+   mode->overscan_top = margin;
+   } else if (!strncmp(option, "overscan_bottom", delim - option)) 
{
+   const char *value = delim + 1;
+ 

[PATCH 6/7] drm/modes: Allow to specify rotation and reflection on the commandline

[Maxime Ripard]

Rotations and reflections setup are needed in some scenarios to initialise
properly the initial framebuffer. Some drivers already had a bunch of
quirks to deal with this, such as either a private kernel command line
parameter (omapdss) or on the device tree (various panels).

In order to accomodate this, let's create a video mode parameter to deal
with the rotation and reflexion.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_fb_helper.c |   4 +-
 drivers/gpu/drm/drm_modes.c | 110 +++--
 include/drm/drm_connector.h |   1 +-
 3 files changed, 95 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cacc4b56344e..1457a1d1a423 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2523,6 +2523,7 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper 
*fb_helper,
struct drm_connector *connector)
 {
struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
+   struct drm_cmdline_mode *mode = &connector->cmdline_mode;
uint64_t valid_mask = 0;
int i, rotation;
 
@@ -2542,6 +2543,9 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper 
*fb_helper,
rotation = DRM_MODE_ROTATE_0;
}
 
+   if (mode->rotation != DRM_MODE_ROTATE_0)
+   fb_crtc->rotation = mode->rotation;
+
/*
 * TODO: support 90 / 270 degree hardware rotation,
 * depending on the hardware this may require the framebuffer
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 3d843d17370a..10c7e9322f76 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1531,6 +1531,71 @@ static int drm_mode_parse_cmdline_res_mode(const char 
*str, unsigned int length,
return 0;
 }
 
+static int drm_mode_parse_cmdline_options(char *str, size_t len,
+ struct drm_connector *connector,
+ struct drm_cmdline_mode *mode)
+{
+   unsigned int rotation = 0;
+   char *sep = str;
+
+   while ((sep = strchr(sep, ','))) {
+   char *delim, *option;
+
+   option = sep + 1;
+   delim = strchr(option, '=');
+   if (!delim) {
+   delim = strchr(option, ',');
+
+   if (!delim)
+   delim = str + len;
+   }
+
+   if (!strncmp(option, "rotate", delim - option)) {
+   const char *value = delim + 1;
+   unsigned int deg;
+
+   deg = simple_strtol(value, &sep, 10);
+
+   /* Make sure we have parsed something */
+   if (sep == value)
+   return -EINVAL;
+
+   switch (deg) {
+   case 0:
+   rotation |= DRM_MODE_ROTATE_0;
+   break;
+
+   case 90:
+   rotation |= DRM_MODE_ROTATE_90;
+   break;
+
+   case 180:
+   rotation |= DRM_MODE_ROTATE_180;
+   break;
+
+   case 270:
+   rotation |= DRM_MODE_ROTATE_270;
+   break;
+
+   default:
+   return -EINVAL;
+   }
+   } else if (!strncmp(option, "reflect_x", delim - option)) {
+   rotation |= DRM_MODE_REFLECT_X;
+   sep = delim;
+   } else if (!strncmp(option, "reflect_y", delim - option)) {
+   rotation |= DRM_MODE_REFLECT_Y;
+   sep = delim;
+   } else {
+   return -EINVAL;
+   }
+   }
+
+   mode->rotation = rotation;
+
+   return 0;
+}
+
 /**
  * drm_mode_parse_command_line_for_connector - parse command line modeline for 
connector
  * @mode_option: optional per connector mode option
@@ -1558,9 +1623,10 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
 {
const char *name;
bool named_mode = false, parse_extras = false;
-   unsigned int bpp_off = 0, refresh_off = 0;
+   unsigned int bpp_off = 0, refresh_off = 0, options_off = 0;
unsigned int mode_end = 0;
char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
+   char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int ret;
 
@@ -1601,13 +1667,18 @@ bool drm_mode_parse_command_line_for_connector(const 
char *mode_option,
mode->refresh_specified = true;
}
 
+   /* Locate the start of named options */
+   options_ptr = strchr(name, '

[PATCH 3/7] drm/edid: Allow to ignore the HDMI monitor mode

[Maxime Ripard]

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_edid.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c0258b011bb2..2f6df10ed9f1 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4156,6 +4156,11 @@ int drm_av_sync_delay(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_av_sync_delay);
 
+static bool force_dvi_monitor = false;
+module_param(force_dvi_monitor, bool, 0644);
+MODULE_PARM_DESC(force_dvi_monitor,
+"Ignore the EDID and always consider the monitor as DVI 
instead of HDMI");
+
 /**
  * drm_detect_hdmi_monitor - detect whether monitor is HDMI
  * @edid: monitor EDID information
@@ -4170,6 +4175,9 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
int i;
int start_offset, end_offset;
 
+   if (force_dvi_monitor)
+   return false;
+
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
return false;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH] dma-buf: Add dma-buf heaps framework

[Andrew F. Davis]

On 3/1/19 6:06 AM, Brian Starkey wrote:
> Hi Andrew,
> 
> Sorry for not managing to comment on this sooner, I've had a crazy few
> days.
> 
> As the others have said, I quite like the direction here.
> 
> On Mon, Feb 25, 2019 at 08:36:04AM -0600, Andrew F. Davis wrote:
>> This framework allows a unified userspace interface for dma-buf
>> exporters, allowing userland to allocate specific types of memory
>> for use in dma-buf sharing.
>>
>> Each heap is given its own device node, which a user can allocate
>> a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
>>
>> Signed-off-by: Andrew F. Davis 
>> ---
>>
>> Hello all,
>>
>> I had a little less time over the weekend than I thought I would to
>> clean this up more and finish the first set of user heaps, but wanted
>> to get this out anyway.
>>
>> ION in its current form assumes a lot about the memory it exports and
>> these assumptions lead to restrictions on the full range of operations
>> dma-buf's can produce. Due to this if we are to add this as an extension
>> of the core dma-buf then it should only be the user-space advertisement
>> and allocation front-end. All dma-buf exporting and operation need to be
>> placed in the control of the exporting heap. The core becomes rather
>> small, just a few hundred lines you see here. This is not to say we
>> should not provide helpers to make the heap exporters more simple, but
>> they should only be helpers and not enforced by the core framework.
>>
>> Basic use model here is an exporter (dedicated heap memory driver, CMA,
>> System, etc.) registers with the framework by providing a struct
>> dma_heap_info which gives us the needed info to export this heap to
>> userspace as a device node. Next a user will request an allocation,
>> the IOCTL is parsed and the request made to a heap provided alloc() op.
>> The heap should return the filled out struct dma_heap_buffer, including
>> exporting the buffer as a dma-buf. This dma-buf we then return to the
>> user as a fd. Buffer free is still a bit open as we need to update some
>> stats and free some memory, but the release operation is controlled by
>> the heap exporter, so some hook will have to be created.
>>
>> It all needs a bit more work, and I'm sure I'll find missing parts when
>> I add some more heaps, but hopefully this framework is simple enough that
>> it does not impede the implementation of all functionality once provided
>> by ION (shrinker, delayed free), nor any new functionality needed for
>> future heap exporting devices.
>>
>> Thanks,
>> Andrew
>>
>>  drivers/dma-buf/Kconfig   |  12 ++
>>  drivers/dma-buf/Makefile  |   1 +
>>  drivers/dma-buf/dma-heap.c| 268 ++
>>  include/linux/dma-heap.h  |  57 
>>  include/uapi/linux/dma-heap.h |  54 +++
>>  5 files changed, 392 insertions(+)
>>  create mode 100644 drivers/dma-buf/dma-heap.c
>>  create mode 100644 include/linux/dma-heap.h
>>  create mode 100644 include/uapi/linux/dma-heap.h
>>
>> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
>> index 2e5a0faa2cb1..30b0d7c83945 100644
>> --- a/drivers/dma-buf/Kconfig
>> +++ b/drivers/dma-buf/Kconfig
>> @@ -39,4 +39,16 @@ config UDMABUF
>>A driver to let userspace turn memfd regions into dma-bufs.
>>Qemu can use this to create host dmabufs for guest framebuffers.
>>  
>> +menuconfig DMABUF_HEAPS
>> +bool "DMA-BUF Userland Memory Heaps"
>> +depends on HAS_DMA && MMU
>> +select GENERIC_ALLOCATOR
>> +select DMA_SHARED_BUFFER
>> +help
>> +  Choose this option to enable the DMA-BUF userland memory heaps,
>> +  this allows userspace to allocate dma-bufs that can be shared between
>> +  drivers.
>> +
>> +source "drivers/dma-buf/heaps/Kconfig"
>> +
>>  endmenu
>> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
>> index 0913a6ccab5a..b0332f143413 100644
>> --- a/drivers/dma-buf/Makefile
>> +++ b/drivers/dma-buf/Makefile
>> @@ -1,4 +1,5 @@
>>  obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
>> +obj-$(CONFIG_DMABUF_HEAPS)  += dma-heap.o
>>  obj-$(CONFIG_SYNC_FILE) += sync_file.o
>>  obj-$(CONFIG_SW_SYNC)   += sw_sync.o sync_debug.o
>>  obj-$(CONFIG_UDMABUF)   += udmabuf.o
>> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
>> new file mode 100644
>> index ..72ed225fa892
>> --- /dev/null
>> +++ b/drivers/dma-buf/dma-heap.c
>> @@ -0,0 +1,268 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Framework for userspace DMA-BUF allocations
>> + *
>> + * Copyright (C) 2011 Google, Inc.
>> + * Copyright (C) 2019 Linaro Ltd.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +#define DEVNAME "dma_heap"
>> +
>> +#define NUM_HEAP_MINORS 128
>> +static DEFINE_IDR(dma_heap_idr);
>> +static DEFINE_MUTEX(minor_lock); /* Protect 

Re: [PATCH 1/7] drm/vc4: hdmi: Check that the monitor supports HDMI audio

[Paul Kocialkowski]

Hi,

On Mon, 2019-03-04 at 15:52 +0100, Maxime Ripard wrote:
> The current code assumes as soon as the device is an HDMI one that it
> supports an audio sink. However, strictly speaking, this is exposed as a
> separate part of EDID.
> 
> This can be checked through the drm_detect_monitor_audio function, so let's
> use it and make sure that we can use the HDMI monitor as an output before
> sending sound.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  drivers/gpu/drm/vc4/vc4_hdmi.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 88fd5df7e7dc..a1bdc065c47c 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -109,6 +109,7 @@ struct vc4_hdmi_encoder {
>   struct vc4_encoder base;
>   bool hdmi_monitor;
>   bool limited_rgb_range;
> + bool monitor_has_audio;
>  };
>  
>  static inline struct vc4_hdmi_encoder *
> @@ -278,6 +279,7 @@ static int vc4_hdmi_connector_get_modes(struct 
> drm_connector *connector)
>   return -ENODEV;
>  
>   vc4_encoder->hdmi_monitor = drm_detect_hdmi_monitor(edid);
> + vc4_encoder->monitor_has_audio = drm_detect_monitor_audio(edid);
>  
>   drm_connector_update_edid_property(connector, edid);
>   ret = drm_add_edid_modes(connector, edid);
> @@ -785,9 +787,13 @@ static int vc4_hdmi_audio_startup(struct 
> snd_pcm_substream *substream,
>  {
>   struct vc4_hdmi *hdmi = dai_to_hdmi(dai);
>   struct drm_encoder *encoder = hdmi->encoder;
> + struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
>   struct vc4_dev *vc4 = to_vc4_dev(encoder->dev);
>   int ret;
>  
> + if (!vc4_encoder->monitor_has_audio)
> + return -ENODEV;
> +
>   if (hdmi->audio.substream && hdmi->audio.substream != substream)
>   return -EINVAL;
>  
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH 3/7] drm/edid: Allow to ignore the HDMI monitor mode

[Paul Kocialkowski]

Hi,

On Mon, 2019-03-04 at 15:52 +0100, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard 

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> ---
>  drivers/gpu/drm/drm_edid.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c0258b011bb2..2f6df10ed9f1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4156,6 +4156,11 @@ int drm_av_sync_delay(struct drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_av_sync_delay);
>  
> +static bool force_dvi_monitor = false;
> +module_param(force_dvi_monitor, bool, 0644);
> +MODULE_PARM_DESC(force_dvi_monitor,
> +  "Ignore the EDID and always consider the monitor as DVI 
> instead of HDMI");
> +
>  /**
>   * drm_detect_hdmi_monitor - detect whether monitor is HDMI
>   * @edid: monitor EDID information
> @@ -4170,6 +4175,9 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
>   int i;
>   int start_offset, end_offset;
>  
> + if (force_dvi_monitor)
> + return false;
> +
>   edid_ext = drm_find_cea_extension(edid);
>   if (!edid_ext)
>   return false;
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH 0/7] drm/vc4: Allow for more boot-time configuration

[Peter Stuge]

Hi,

Maxime Ripard wrote:
> properties to initialise the overscan or rotation parameters, or the
> one to deal with broken displays.

How does that work on systems with multiple connectors?

On SBCs with only one output I guess it's fine to have a global option,
but it may be important for new options to also be usable on more
complex systems. And maybe even SPI displays are relevant?

Also, some of the forward-ported patches still have your old email
address, maybe you want to change that.


Thanks

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

[Bug 109808] ROCm OpenCL segfaults on drm-next-5.1-wip

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109808

--- Comment #4 from Philip Yang  ---
I will change the error message for this specific case to mention the missing
kernel config option.

I cannot add select ZONE_DEVICE in driver Kconfig file because there will be a
circular dependency issue. The old or wired kernel config file may select to
don't enable HMM or ZONE_DEVICE.

Thanks,
Philip

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

Re: [PATCH v9 2/5] drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits

[Maxime Ripard]

On Sun, Mar 03, 2019 at 11:05:24PM +0530, Jagan Teki wrote:
> TCON DRQ for non-burst DSI mode can computed based on horizontal
> front porch value, but the current driver trying to include sync
> timings along with front porch resulting wrong drq.
> 
> This patch is trying to update the drq by subtracting hsync_start
> with hdisplay, which is horizontal front porch.
> 
> Current code:
> 
> mode->hsync_end - mode->hdisplay => horizontal front porch + sync
> 
> With this patch:
> 
> mode->hsync_start - mode->hdisplay => horizontal front porch
> 
> BSP code form BPI-M64-bsp is computing TCON DRQ set bits
> for non-burts as (from linux-sunxi/
> drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> 
> => panel->lcd_ht -panel->lcd_x - panel->lcd_hbp
> => (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x)
  ^ + sync length +  
>- panel->lcd_x - panel->hbp
> => timmings->hor_front_porch
   ^ + sync
> => mode->hsync_start - mode->hdisplay

s/hsync_start/hsync_end/

Did you encounter any panel where this was fixing something? If so,
which one, and what is the matching timings and / or datasheet?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data

[Jani Nikula]

On Mon, 04 Mar 2019, Maxime Ripard  wrote:
> In some cases, in order to accomodate with displays with poor EDIDs, we
> need to ignore that the monitor alledgedly supports audio output and
> disable the audio output.

*sad trombone*

Trying to figure this out automatically in kernel is better than a
quirk.

A quirk is better than requiring the user to provide an override EDID
via the firmware loader (drm.edid_firmware parameter).

Requiring an override EDID is better than adding a module parameter.

I'd much rather we exhausted the other options before adding module
parameters to address specific issues with EDIDs. That's a rabbit hole
with no end.


BR,
Jani.


>
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/drm_edid.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 990b1909f9d7..c0258b011bb2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
>  }
>  EXPORT_SYMBOL(drm_detect_hdmi_monitor);
>  
> +static bool ignore_edid_audio = false;
> +module_param(ignore_edid_audio, bool, 0644);
> +MODULE_PARM_DESC(ignore_edid_audio,
> +  "Ignore the EDID and always consider that a monitor doesn't 
> have audio capabilities");
> +
>  /**
>   * drm_detect_monitor_audio - check monitor audio capability
>   * @edid: EDID block to scan
> @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *edid)
>   bool has_audio = false;
>   int start_offset, end_offset;
>  
> + if (ignore_edid_audio)
> + goto end;
> +
>   edid_ext = drm_find_cea_extension(edid);
>   if (!edid_ext)
>   goto end;

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/7] drm/edid: Allow to ignore the HDMI monitor mode

[Jani Nikula]

On Mon, 04 Mar 2019, Maxime Ripard  wrote:
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/drm_edid.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c0258b011bb2..2f6df10ed9f1 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4156,6 +4156,11 @@ int drm_av_sync_delay(struct drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_av_sync_delay);
>  
> +static bool force_dvi_monitor = false;
> +module_param(force_dvi_monitor, bool, 0644);
> +MODULE_PARM_DESC(force_dvi_monitor,
> +  "Ignore the EDID and always consider the monitor as DVI 
> instead of HDMI");
> +

Same reply as with patch 2/7.

BR,
Jani.

>  /**
>   * drm_detect_hdmi_monitor - detect whether monitor is HDMI
>   * @edid: monitor EDID information
> @@ -4170,6 +4175,9 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
>   int i;
>   int start_offset, end_offset;
>  
> + if (force_dvi_monitor)
> + return false;
> +
>   edid_ext = drm_find_cea_extension(edid);
>   if (!edid_ext)
>   return false;

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm: don't block fb changes for async plane updates

[Kazlauskas, Nicholas]

On 3/4/19 9:49 AM, Helen Koike wrote:
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are performed in the new_state and the respective
> cleanups are performed in the old_state.
> 
> In the case of async updates, the preparation is also done in the
> new_state but the cleanups are done in the new_state (because updates
> are performed in place, i.e. in the current state).
> 
> The current code blocks async udpates when the fb is changed, turning
> async updates into sync updates, slowing down cursor updates and
> introducing regressions in igt tests with errors of type:
> 
> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
> expect to complete approximately 15360 updates, with the threshold set
> at 7680"
> 
> Fb changes in async updates were prevented to avoid the following scenario:
> 
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
> Where we have a single call to prepare fb2 but double cleanup call to fb2.
> 
> To solve the above problems, instead of blocking async fb changes, we
> place the old framebuffer in the new_state object, so when the code
> performs cleanups in the new_state it will cleanup the old_fb and we
> will have the following scenario instead:
> 
> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
> 
> Where calls to prepare/cleanup are ballanced.
> 
> Cc:  # v4.14+: 25dc194b34dd: drm: Block fb changes 
> for async plane updates
> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
> Suggested-by: Boris Brezillon 
> Signed-off-by: Helen Koike 
> 
> ---
> Hello,
> 
> As mentioned in the cover letter,
> I tested on the rockchip and on i915 (with a patch I am still working on for
> replacing cursors by async update), with igt plane_cursor_legacy and
> kms_cursor_legacy and I didn't see any regressions.
> I couldn't test on MSM and AMD because I don't have the hardware (and I am
> having some issues testing on vc4) and I would appreciate if anyone could help
> me testing those.
> 
> I also think it would be a better solution if, instead of having async
> to do in-place updates in the current state, the async path should be
> equivalent to a syncronous update, i.e., modifying new_state and
> performing a flip
> IMHO, the only difference between sync and async should be that async update
> doesn't wait for vblank and applies the changes immeditally to the hw,
> but the code path could be almost the same.
> But for now I think this solution is ok (swaping new_fb/old_fb), and
> then we can adjust things little by little, what do you think?
> 
> Thanks!
> Helen
> 
>   drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
>   1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 540a77a2ade9..e7eb96f1efc2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device 
> *dev,
>   old_plane_state->crtc != new_plane_state->crtc)
>   return -EINVAL;
>   
> - /*
> -  * FIXME: Since prepare_fb and cleanup_fb are always called on
> -  * the new_plane_state for async updates we need to block framebuffer
> -  * changes. This prevents use of a fb that's been cleaned up and
> -  * double cleanups from occuring.
> -  */
> - if (old_plane_state->fb != new_plane_state->fb)
> - return -EINVAL;
> -
>   funcs = plane->helper_private;
>   if (!funcs->atomic_async_update)
>   return -EINVAL;
> @@ -1657,6 +1648,9 @@ void drm_atomic_helper_async_commit(struct drm_device 
> *dev,
>   int i;
>   
>   for_each_new_plane_in_state(state, plane, plane_state, i) {
> + struct drm_framebuffer *new_fb = plane_state->fb;
> + struct drm_framebuffer *old_fb = plane->state->fb;
> +
>   funcs = plane->helper_private;
>   funcs->atomic_async_update(plane, plane_state);
>   
> @@ -1665,11 +1659,17 @@ void drm_atomic_helper_async_commit(struct drm_device 
> *dev,
>* plane->state in-place, make sure at least common
>* properties have been properly updated.
>*/
> - WARN_ON_ONCE(plane->state->fb != plane_state->fb);
> + WARN_ON_ONCE(plane->state->fb != new_fb);
>   WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
>   WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
>   WARN_ON_ONCE(pl

Re: [PATCH v9 3/5] drm/sun4i: sun6i_mipi_dsi: Support vblk timing for 4-lane devices

[Maxime Ripard]

On Sun, Mar 03, 2019 at 11:05:25PM +0530, Jagan Teki wrote:
> Like other dsi setup timings, or hblk for that matter vblk would
> also require compute the timings based payload equation along with
> packet overhead.
> 
> But, on the other hand vblk computation is also depends on device
> lane number.
> - for 4 lane devices, it is computed based on vtotal, packet overhead
>   along with hblk value.
> - for others devices, it is simply 0
> 
> BSP code from BPI-M64-bsp is computing vblk as for 4-lane devices
> (from linux-sunxi
> drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> 
> tmp = (ht*dsi_pixel_bits[format]/8)*vt-(4+dsi_hblk+2);
> dsi_vblk = (lane-tmp%lane);
> 
> So, update the vblk timing calculation to support all type of
> devices.
> 
> Tested on 2-lane, 4-lane MIPI-DSI LCD panels.

You should be explaining which issue you faced, in which setup, what
were its symptoms and how that solution is fixing it.

> Signed-off-by: Jagan Teki 
> Tested-by: Merlijn Wajer 
> ---
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 27 +++---
>  1 file changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 140e55f5ed2e..b38358465d87 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -527,6 +527,24 @@ static void sun6i_dsi_setup_format(struct sun6i_dsi *dsi,
>SUN6I_DSI_PIXEL_CTL0_FORMAT(fmt));
>  }
>  
> +static u16 sun6i_dsi_get_timings_vblk(struct sun6i_dsi *dsi,
> +   struct drm_display_mode *mode, u16 hblk)
> +{
> + struct mipi_dsi_device *device = dsi->device;
> + unsigned int Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
> + int tmp;
> +
> + /*
> +  * The vertical blank is set using a blanking packet (4 bytes +
> +  * payload + 2 bytes). Its minimal size is therefore 6 bytes
> +  */
> +#define VBLK_PACKET_OVERHEAD 6
> + tmp = (mode->htotal * Bpp) * mode->vtotal -
> +   (hblk + VBLK_PACKET_OVERHEAD);
> +
> + return (device->lanes - tmp % device->lanes);

This should have a comment explaining why it's needed

> +}
> +
>  static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
>   struct drm_display_mode *mode)
>  {
> @@ -586,13 +604,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi 
> *dsi,
>  (mode->htotal - (mode->hsync_end - 
> mode->hsync_start)) * Bpp -
>  HBLK_PACKET_OVERHEAD);
>  
> - /*
> -  * And I'm not entirely sure what vblk is about. The driver in
> -  * Allwinner BSP is using a rather convoluted calculation
> -  * there only for 4 lanes. However, using 0 (the !4 lanes
> -  * case) even with a 4 lanes screen seems to work...
> -  */
> - vblk = 0;
> + if (device->lanes == 4)

And that can be done in the function itself.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH 0/7] drm/vc4: Allow for more boot-time configuration

[Stefan Wahren]

Hi Maxime,

Am 04.03.2019 um 15:52 schrieb Maxime Ripard:

Hi,

The proprietary stack for the RaspberryPi allows for a number of video
parameters widely used by their users, but yet don't have any equivalents
in the mainline kernel.

Those options are detailed here:
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

While not all of them are desirable to have in the mainline kernel, some of
them still have value, such as properties to initialise the overscan or
rotation parameters, or the one to deal with broken displays.

This series is an attempt to support those, and is based on a rewrite of
the command line parser I did a couple of years ago that never reached
upstream (due to a lack of time on my side). While this parser was
initially made to deal with named modes (in order to support TV modes), it
also allowed to extend it more easily, which is why it's resurrected.

Since a change of the command line parser can pretty easily get things
wrong and introduce regressions, I also worked with a number of unit tests
that you can find here: http://code.bulix.org/tpo7dg-607264?raw

Eventually, I guess those tests should be part of the kernel somewhere, but
I haven't found a suitable place for them to be included yet.

Let me know what you think,
Maxime

thanks for this series. In case you want some feedback from the 
Foundation, please add Phil Elwell instead of Eben to CC.


Stefan

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

Re: [PATCH v9 5/5] drm/sun4i: sun6i_mipi_dsi: Simplify dsi setup timings code

[Maxime Ripard]

On Sun, Mar 03, 2019 at 11:05:27PM +0530, Jagan Teki wrote:
> DSI timings are varies between burst/non-burst devices and
> current driver is handling this support via if, else statements
> which would difficult to read.
> 
> Simplify it by using goto to make code more readable.
> 
> Signed-off-by: Jagan Teki 
> Tested-by: Merlijn Wajer 
> ---
> Note: This change is created based on previous version burst
> changes [1] by addressing comment from [2] by Maxime to make
> code readable. 
> 
> [1] https://patchwork.kernel.org/cover/10813623/
> [2] https://patchwork.kernel.org/patch/1007/
> 
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 79 ++
>  1 file changed, 42 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 31ec4048804d..898f32319c2d 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -550,7 +550,8 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
>  {
>   struct mipi_dsi_device *device = dsi->device;
>   unsigned int Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
> - u16 hbp = 0, hfp = 0, hsa = 0, hblk = 0, vblk = 0;
> + u16 hbp, hfp, hsa, hblk;
> + u16 vblk = 0;
>   u32 basic_ctl = 0;
>   size_t bytes;
>   u8 *buffer;
> @@ -558,6 +559,7 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
>   /* Do all timing calculations up front to allocate buffer space */
>  
>   if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> + hbp = hfp = hsa = 0;

This raises a checkpatch warning and isn't necessary

>   hblk = mode->hdisplay * Bpp;
>   basic_ctl = SUN6I_DSI_BASIC_CTL_VIDEO_BURST |
>   SUN6I_DSI_BASIC_CTL_HSA_HSE_DIS |
> @@ -566,48 +568,51 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi 
> *dsi,
>   if (device->lanes == 4)
>   basic_ctl |= SUN6I_DSI_BASIC_CTL_TRAIL_FILL |
>SUN6I_DSI_BASIC_CTL_TRAIL_INV(0xc);
> - } else {
> - /*
> -  * A sync period is composed of a blanking packet (4
> -  * bytes + payload + 2 bytes) and a sync event packet
> -  * (4 bytes). Its minimal size is therefore 10 bytes
> -  */
> +
> + goto alloc_buf;

And I'd rather not have a goto in the middle of the code for no
particular reason.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data

[Adam Jackson]

On Mon, 2019-03-04 at 17:47 +0200, Jani Nikula wrote:
> On Mon, 04 Mar 2019, Maxime Ripard  wrote:
> > In some cases, in order to accomodate with displays with poor EDIDs, we
> > need to ignore that the monitor alledgedly supports audio output and
> > disable the audio output.
> 
> *sad trombone*
> 
> Trying to figure this out automatically in kernel is better than a
> quirk.
> 
> A quirk is better than requiring the user to provide an override EDID
> via the firmware loader (drm.edid_firmware parameter).
> 
> Requiring an override EDID is better than adding a module parameter.

Also, this and 3/ apply to _every_ monitor attached to the system. No.

- ajax

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

Re: [PATCH 3/5] drm/amd: fix fb references in async update

[Kazlauskas, Nicholas]

On 3/4/19 9:49 AM, Helen Koike wrote:
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
> 
> Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
> fb and put the old fb) is not required, as it's taken care by
> drm_mode_cursor_universal() when calling drm_atomic_helper_update_plane().
> 
> Suggested-by: Boris Brezillon 
> Signed-off-by: Helen Koike 

Reviewed-by: Nicholas Kazlauskas 

I guess the swap itself should be enough here as per the commit description.

It would have been nice if this patch dropped the old_plane_state->fb != 
new_plane_state->fb check too at the same time, but I suppose I can drop 
that later. It'll help us pass those failing IGT tests as well.

Nicholas Kazlauskas


> 
> ---
> Hello,
> 
> As mentioned in the cover letter,
> I tested on the rockchip and on i915 using igt plane_cursor_legacy and
> kms_cursor_legacy and I didn't see any regressions.
> But I couldn't test on AMD because I don't have the hardware and I would
> appreciate if anyone could test it.
> 
> Also, I didn't CC to stable here as I saw the async_update function was only
> added on v4.20, please let me know if I should CC to stable.
> 
> Thanks!
> Helen
> 
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 3a6f595f295e..bc02800254bf 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3760,8 +3760,7 @@ static void dm_plane_atomic_async_update(struct 
> drm_plane *plane,
>   struct drm_plane_state *old_state =
>   drm_atomic_get_old_plane_state(new_state->state, plane);
>   
> - if (plane->state->fb != new_state->fb)
> - drm_atomic_set_fb_for_plane(plane->state, new_state->fb);
> + swap(plane->state->fb, new_state->fb);
>   
>   plane->state->src_x = new_state->src_x;
>   plane->state->src_y = new_state->src_y;
> 

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

Re: [PATCH v9 1/5] drm/sun4i: sun6i_mipi_dsi: Fix hsync_porch overflow

[Maxime Ripard]

On Sun, Mar 03, 2019 at 11:05:23PM +0530, Jagan Teki wrote:
> Loop N1 instruction delay for burst mode devices are computed
> based on horizontal sync and porch timing values.
> 
> The current driver is using u16 type for computing this hsync_porch
> value, which would failed to fit within the u16 type for large sync
> and porch timings devices. This would result in hsync_porch overflow
> and eventually computed wrong instruction delay value.
> 
> Example, timings, where it produces the overflow
> {
>   .hdisplay   = 1080,
>   .hsync_start= 1080 + 408,
> .hsync_end  = 1080 + 408 + 4,
> .htotal = 1080 + 408 + 4 + 38,
> }
> 
> It reproduces the desired delay value 65487 but the correct working
> value should be 7.
> 
> So, Fix it by computing hsync_porch value separately with u32 type.
> 
> Fixes: 1c1a7aa3663c ("drm/sun4i: dsi: Add burst support")
> Signed-off-by: Jagan Teki 
> Tested-by: Merlijn Wajer 
> ---
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index 6ff585055a07..465e7fc57899 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -457,8 +457,9 @@ static void sun6i_dsi_setup_inst_loop(struct sun6i_dsi 
> *dsi,
>   u16 delay = 50 - 1;
>  
>   if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> - delay = (mode->htotal - mode->hdisplay) * 150;
> - delay /= (mode->clock / 1000) * 8;
> + u32 hsync_porch = (mode->htotal - mode->hdisplay);
> +
> + delay = ((hsync_porch * 150) / ((mode->clock / 1000) * 8));

shouldn't we keep the multiplication by 150 in the u32 assignation?
Otherwise, we could keep a u16 for the delay

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH 1/7] drm/vc4: hdmi: Check that the monitor supports HDMI audio

[Stefan Wahren]

Hi Maxime,

Am 04.03.2019 um 15:52 schrieb Maxime Ripard:

The current code assumes as soon as the device is an HDMI one that it
supports an audio sink. However, strictly speaking, this is exposed as a
separate part of EDID.

This can be checked through the drm_detect_monitor_audio function, so let's
use it and make sure that we can use the HDMI monitor as an output before
sending sound.


does the audio output work in the following setup after applying this patch?

VC4 --- HDMI Audio extractor --- Non audio capable monitor



Signed-off-by: Maxime Ripard 


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

Re: [PATCH 0/7] drm/vc4: Allow for more boot-time configuration

[Maxime Ripard]

Hi Peter,

On Mon, Mar 04, 2019 at 03:21:35PM +, Peter Stuge wrote:
> Hi,
> 
> Maxime Ripard wrote:
> > properties to initialise the overscan or rotation parameters, or the
> > one to deal with broken displays.
> 
> How does that work on systems with multiple connectors?
> 
> On SBCs with only one output I guess it's fine to have a global option,
> but it may be important for new options to also be usable on more
> complex systems. And maybe even SPI displays are relevant?

These properties are per-connector, so only the display attached to
that connector will be affected, and you can have multiple connectors
with various properties and values defined if you want to

> Also, some of the forward-ported patches still have your old email
> address, maybe you want to change that.

Good catch, thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [PATCH 2/7] drm/edid: Allow to ignore the audio EDID data

[Ville Syrjälä]

On Mon, Mar 04, 2019 at 03:52:35PM +0100, Maxime Ripard wrote:
> In some cases, in order to accomodate with displays with poor EDIDs, we
> need to ignore that the monitor alledgedly supports audio output and
> disable the audio output.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/drm_edid.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 990b1909f9d7..c0258b011bb2 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4190,6 +4190,11 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
>  }
>  EXPORT_SYMBOL(drm_detect_hdmi_monitor);
>  
> +static bool ignore_edid_audio = false;
> +module_param(ignore_edid_audio, bool, 0644);
> +MODULE_PARM_DESC(ignore_edid_audio,
> +  "Ignore the EDID and always consider that a monitor doesn't 
> have audio capabilities");
> +

I would suggest that this is not the best apporach. Years of experience
from i915 says that more modparams means random forums full of people
trading  cargo culted settings. And as soon as the average user comes
across the magic incantation that works they are likely to not file the
appropriate bug report. Also years later we still see people using
modparams that stopped working five hardware generations ago. So at
least for i915 new modparams are generally frowned upon.

Bad EDIDs at least should be quirked. Which means we really need the
bug reports, and hence a modparam can be somewhat counter productive.

For allowing the user to force the DVI vs. HDMI and audio vs. not i915
does have the "audio" connector property. Other drivers could adopt the
same thing. Though I'm not sure even i915 should be exposing this for
the reasons already mentioned. There is one hardware generation where
it can actually be useful on i915 as the hardware is only capably of
sending infoframes/audio to a single HDMI port at a time. So with this
property the user can at least select which display gets to do those
things.

I do agree that there is an unfortnate problem with fbcon vs.
initial property values. I've sometimes pondered about exposing
kms properties in a generic fashion via sysfs and/or kernel
cmdline somehow. IIRC devicetree/something similar has also been
proposed occasionally to solve this problem.

>  /**
>   * drm_detect_monitor_audio - check monitor audio capability
>   * @edid: EDID block to scan
> @@ -4209,6 +4214,9 @@ bool drm_detect_monitor_audio(struct edid *edid)
>   bool has_audio = false;
>   int start_offset, end_offset;
>  
> + if (ignore_edid_audio)
> + goto end;
> +
>   edid_ext = drm_find_cea_extension(edid);
>   if (!edid_ext)
>   goto end;
> -- 
> git-series 0.9.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: [PATCH v2 3/5] drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.

On Wed, Feb 27, 2019 at 11:54:21PM +0200, Jyri Sarha wrote:
> The pixel clock unit in the first two registers (0x00 and 0x01) of
> sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
> 10 fixes the issue.
> 
> Signed-off-by: Jyri Sarha 
> Reviewed-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/bridge/sii902x.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/sii902x.c 
> b/drivers/gpu/drm/bridge/sii902x.c
> index 0e21fa419d27..1e91ed72 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -248,10 +248,11 @@ static void sii902x_bridge_mode_set(struct drm_bridge 
> *bridge,
>   struct regmap *regmap = sii902x->regmap;
>   u8 buf[HDMI_INFOFRAME_SIZE(AVI)];
>   struct hdmi_avi_infoframe frame;
> + u16 pixel_clock_10kHz = adj->clock / 10;
>   int ret;
>  
> - buf[0] = adj->clock;
> - buf[1] = adj->clock >> 8;
> + buf[0] = pixel_clock_10kHz & 0xFF;

Nitpicking, we usually use lowercase hex values.

Apart from that,

Reviewed-by: Laurent Pinchart 

> + buf[1] = pixel_clock_10kHz >> 8;
>   buf[2] = adj->vrefresh;
>   buf[3] = 0x00;
>   buf[4] = adj->hdisplay;

-- 
Regards,

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

Re: [PATCH v2 4/5] drm/bridge: sii902x: Select I2C_MUX

[Laurent Pinchart]

Hi Jyri,

Thank you for the patch.

On Wed, Feb 27, 2019 at 11:54:22PM +0200, Jyri Sarha wrote:
> "drm/bridge/sii902x: Fix EDID readback"-commit added a dependency to
> I2C_MUX, but not indicate it in the Kconfig entry. Fix it by selecting
> I2C_MUX for DRM_SII902X config option.
> 
> Fixes: 88664675239 ("drm/bridge/sii902x: Fix EDID readback")
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/bridge/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index fb0b37918382..a6f6ff8f06b3 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -95,6 +95,7 @@ config DRM_SII902X
>   depends on OF
>   select DRM_KMS_HELPER
>   select REGMAP_I2C
> + select I2C_MUX
>   ---help---
> Silicon Image sii902x bridge chip driver.
>  

This is already present in v5.0.

commit ea6b13e9fed0fda9532ee04d38ed1bef1edbfdbf
Author: Fabrizio Castro 
Date:   Mon Nov 19 13:26:18 2018 +

drm/bridge/sii902x: Add missing dependency on I2C_MUX

Fabrizio stated in the commit message that "Quite obviously the driver
depends on I2C_MUX, but adding a "depends on" introduces a recursive
dependency, therefore this patch selects I2C_MUX instead.". Given that
I2C_MUX is a tristate user-selectable option, "depend on" should be the
right solution. I wonder if we could fix the root cause of the recursive
dependency.

-- 
Regards,

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

Re: [PATCH] drm: add __user attribute to ptr_to_compat()

[Sean Paul]

On Fri, Mar 01, 2019 at 12:00:46PM +, Ben Dooks wrote:
> The ptr_to_compat() call takes a "void __user *", so cast
> the compat drm calls that use it to avoid the following
> warnings from sparse:
> 
> drivers/gpu/drm/drm_ioc32.c:188:39: warning: incorrect type in argument 1 
> (different address spaces)
> drivers/gpu/drm/drm_ioc32.c:188:39:expected void [noderef] *uptr
> drivers/gpu/drm/drm_ioc32.c:188:39:got void *[addressable] [assigned] 
> handle
> drivers/gpu/drm/drm_ioc32.c:529:41: warning: incorrect type in argument 1 
> (different address spaces)
> drivers/gpu/drm/drm_ioc32.c:529:41:expected void [noderef] *uptr
> drivers/gpu/drm/drm_ioc32.c:529:41:got void *[addressable] [assigned] 
> handle
> 
> Signed-off-by: Ben Dooks 

Thanks for your patch, I've applied it to drm-misc-next-fixes with cc: stable.

Sean

> ---
>  drivers/gpu/drm/drm_ioc32.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index 67b1fca39aa6..0e3043e08c69 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -185,7 +185,7 @@ static int compat_drm_getmap(struct file *file, unsigned 
> int cmd,
>   m32.size = map.size;
>   m32.type = map.type;
>   m32.flags = map.flags;
> - m32.handle = ptr_to_compat(map.handle);
> + m32.handle = ptr_to_compat((void __user *)map.handle);
>   m32.mtrr = map.mtrr;
>   if (copy_to_user(argp, &m32, sizeof(m32)))
>   return -EFAULT;
> @@ -216,7 +216,7 @@ static int compat_drm_addmap(struct file *file, unsigned 
> int cmd,
>  
>   m32.offset = map.offset;
>   m32.mtrr = map.mtrr;
> - m32.handle = ptr_to_compat(map.handle);
> + m32.handle = ptr_to_compat((void __user *)map.handle);
>   if (map.handle != compat_ptr(m32.handle))
>   pr_err_ratelimited("compat_drm_addmap truncated handle %p for 
> type %d offset %x\n",
>  map.handle, m32.type, m32.offset);
> @@ -526,7 +526,7 @@ static int compat_drm_getsareactx(struct file *file, 
> unsigned int cmd,
>   if (err)
>   return err;
>  
> - req32.handle = ptr_to_compat(req.handle);
> + req32.handle = ptr_to_compat((void __user *)req.handle);
>   if (copy_to_user(argp, &req32, sizeof(req32)))
>   return -EFAULT;
>  
> -- 
> 2.20.1
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/5] drm/bridge: sii902x: HDMI-audio support and some fixes

[Laurent Pinchart]

Hi Jyri,

On Mon, Mar 04, 2019 at 04:29:17PM +0200, Jyri Sarha wrote:
> On 04/03/2019 14:42, Laurent Pinchart wrote:
> > On Wed, Feb 27, 2019 at 11:54:18PM +0200, Jyri Sarha wrote:
> >> Changes since first version:
> >> - Moved reviewed patches to front:
> >>   - drm/bridge: sii902x: add input_bus_flags
> >>   - drm/bridge: sii902x: Set output mode to HDMI or DVI according to EDID
> >>   - drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
> >> - Added a new fix:
> >>   - drm/bridge: sii902x: Select I2C_MUX
> >> - Applied some review suggestions to
> >>   - drm/bridge: sii902x: Implement HDMI audio support
> >> - use clock-names property to name mclk
> >> - move comment describing added mutex to struct sii902x and improve it
> >> - cleanup sii902x_mute()
> >> - cleanup sii902x_select_mclk_div()
> >> - fix condition for checking ENABLE_BIT from i2s_fifo_routing in
> >>   sii902x_audio_codec_init()
> >>
> >> Still to do
> >>
> >> - Agree on i2s wires to HDMI audio fifo routing in dts. 
> >>
> >>   The current scheme is quite straight forward, but there is maybe
> >>   there is even more straight forward solutions like:
> >>
> >>   audio-fifo-enable = <1 1 1 1>;
> >>   audio-i2s-pin-to-fifo = <0 1 2 3>;
> >>
> >>   Meaning that all fifos are enabled and SD0 is routed to fifo 0, SD1
> >>   to fifo 1, etc. I am not sure if the channel swap functionality
> >>   should show in dts binding.
> > 
> > Please forgive my lack of audio knowledge, but it this a system
> > description that should be encoded in DT, or a policy that should be
> > handled purely in software (either fully inside the kernel or with the
> > help of userspace) ?
> 
> This property describes how many i2s wires are connected to sii902x and
> in what order, so I think it belongs to DTS.

That would belong to DT, yes. We have solved a similar problem with
CSI-2 receivers, where the number of data lanes and their mapping can
often be configured. See the definition of the data-lanes property in
Documentation/devicetree/bindings/media/video-interfaces.txt for more
information. How about using similar bindings ? It would also solve
Andrzej's concerns that you don't describe the audio connection in DT.

> One might of course wonder why anybody would put the i2s wires to any
> other order than 0 <-> 0, 1 <-> 1, 2 <-> 2, and 3 <-> 3, but then a
> again I've seen weirder board designs.

It can be useful to simplify signal routing on the board.

-- 
Regards,

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

Re: [PATCH] drm: fix spelling mistake "intead" -> "instead"

[Sean Paul]

On Sun, Feb 17, 2019 at 10:55:54PM +, Colin King wrote:
> From: Colin Ian King 
> 
> There is a spelling mistake in a DRM_NOTE message. Fix this.
> 
> Signed-off-by: Colin Ian King 

Applied to drm-misc-next, thanks.

Sean

> ---
>  drivers/gpu/drm/drm_kms_helper_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_kms_helper_common.c 
> b/drivers/gpu/drm/drm_kms_helper_common.c
> index 93e2b30fe1a5..9c5ae825c507 100644
> --- a/drivers/gpu/drm/drm_kms_helper_common.c
> +++ b/drivers/gpu/drm/drm_kms_helper_common.c
> @@ -39,7 +39,7 @@ MODULE_LICENSE("GPL and additional rights");
>  /* Backward compatibility for drm_kms_helper.edid_firmware */
>  static int edid_firmware_set(const char *val, const struct kernel_param *kp)
>  {
> - DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use 
> drm.edid_firmware intead.\n");
> + DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use 
> drm.edid_firmware instead.\n");
>  
>   return __drm_set_edid_firmware_path(val);
>  }
> -- 
> 2.20.1
> 

-- 
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 3/3] drm/vboxvideo: Move the vboxvideo driver out of staging

[Hans de Goede]

The vboxvideo driver has been converted to the atomic modesetting API
and all FIXME and TODO items have been fixed, so it is time to move it out
of staging.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/Kconfig  | 2 ++
 drivers/gpu/drm/Makefile | 1 +
 drivers/{staging => gpu/drm}/vboxvideo/Kconfig   | 0
 drivers/{staging => gpu/drm}/vboxvideo/Makefile  | 0
 drivers/{staging => gpu/drm}/vboxvideo/hgsmi_base.c  | 0
 drivers/{staging => gpu/drm}/vboxvideo/hgsmi_ch_setup.h  | 0
 drivers/{staging => gpu/drm}/vboxvideo/hgsmi_channels.h  | 0
 drivers/{staging => gpu/drm}/vboxvideo/hgsmi_defs.h  | 0
 drivers/{staging => gpu/drm}/vboxvideo/modesetting.c | 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_drv.c| 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_drv.h| 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_fb.c | 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_hgsmi.c  | 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_irq.c| 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_main.c   | 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_mode.c   | 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_prime.c  | 0
 drivers/{staging => gpu/drm}/vboxvideo/vbox_ttm.c| 0
 drivers/{staging => gpu/drm}/vboxvideo/vboxvideo.h   | 0
 drivers/{staging => gpu/drm}/vboxvideo/vboxvideo_guest.h | 0
 drivers/{staging => gpu/drm}/vboxvideo/vboxvideo_vbe.h   | 0
 drivers/{staging => gpu/drm}/vboxvideo/vbva_base.c   | 0
 drivers/staging/Kconfig  | 2 --
 drivers/staging/Makefile | 1 -
 drivers/staging/vboxvideo/TODO   | 7 ---
 25 files changed, 3 insertions(+), 10 deletions(-)
 rename drivers/{staging => gpu/drm}/vboxvideo/Kconfig (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/Makefile (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/hgsmi_base.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/hgsmi_ch_setup.h (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/hgsmi_channels.h (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/hgsmi_defs.h (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/modesetting.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_drv.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_drv.h (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_fb.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_hgsmi.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_irq.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_main.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_mode.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_prime.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbox_ttm.c (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vboxvideo.h (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vboxvideo_guest.h (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vboxvideo_vbe.h (100%)
 rename drivers/{staging => gpu/drm}/vboxvideo/vbva_base.c (100%)
 delete mode 100644 drivers/staging/vboxvideo/TODO

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4385f00e1d05..2aa26dd23271 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -333,6 +333,8 @@ source "drivers/gpu/drm/tve200/Kconfig"
 
 source "drivers/gpu/drm/xen/Kconfig"
 
+source "drivers/gpu/drm/vboxvideo/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ce8d1d384319..4d3e101c9f9d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -109,3 +109,4 @@ obj-$(CONFIG_DRM_TINYDRM) += tinydrm/
 obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
 obj-$(CONFIG_DRM_XEN) += xen/
+obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
diff --git a/drivers/staging/vboxvideo/Kconfig 
b/drivers/gpu/drm/vboxvideo/Kconfig
similarity index 100%
rename from drivers/staging/vboxvideo/Kconfig
rename to drivers/gpu/drm/vboxvideo/Kconfig
diff --git a/drivers/staging/vboxvideo/Makefile 
b/drivers/gpu/drm/vboxvideo/Makefile
similarity index 100%
rename from drivers/staging/vboxvideo/Makefile
rename to drivers/gpu/drm/vboxvideo/Makefile
diff --git a/drivers/staging/vboxvideo/hgsmi_base.c 
b/drivers/gpu/drm/vboxvideo/hgsmi_base.c
similarity index 100%
rename from drivers/staging/vboxvideo/hgsmi_base.c
rename to drivers/gpu/drm/vboxvideo/hgsmi_base.c
diff --git a/drivers/staging/vboxvideo/hgsmi_ch_setup.h 
b/drivers/gpu/drm/vboxvideo/hgsmi_ch_setup.h
similarity index 100%
rename from drivers/staging/vboxvideo/hgsmi_ch_setup.h
rename to drivers/gpu/drm/vboxvideo/hgsmi_ch_setup.h
diff --git a/drivers/staging/vboxvideo/hgsmi_channels.h 
b/drivers/gpu/drm/vboxvideo/hgsmi_channels.h
similarity index 100%
rename from drivers/staging/vboxvideo/hgsmi_channels.h
rename to drivers/gpu/drm/vboxvideo/hgsmi_ch

[PATCH 2/3] staging/vboxvideo: Refactor vbox_update_mode_hints

[Hans de Goede]

Refactor vbox_update_mode_hints to no longer use the obsolete
drm_modeset_lock_all() and switch it over to drm_connector_list_iter
instead of directly accessing the list using list_for_each_entry.

Signed-off-by: Hans de Goede 
---
 drivers/staging/vboxvideo/vbox_irq.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/vboxvideo/vbox_irq.c 
b/drivers/staging/vboxvideo/vbox_irq.c
index 89944134ea86..16a1e29f5292 100644
--- a/drivers/staging/vboxvideo/vbox_irq.c
+++ b/drivers/staging/vboxvideo/vbox_irq.c
@@ -105,6 +105,7 @@ static void validate_or_set_position_hints(struct 
vbox_private *vbox)
 /* Query the host for the most recent video mode hints. */
 static void vbox_update_mode_hints(struct vbox_private *vbox)
 {
+   struct drm_connector_list_iter conn_iter;
struct drm_device *dev = &vbox->ddev;
struct drm_connector *connector;
struct vbox_connector *vbox_conn;
@@ -122,13 +123,10 @@ static void vbox_update_mode_hints(struct vbox_private 
*vbox)
}
 
validate_or_set_position_hints(vbox);
-   drm_modeset_lock_all(dev);
-   /*
-* FIXME: this needs to use drm_connector_list_iter and some real
-* locking for the actual data it changes, not the deprecated
-* drm_modeset_lock_all() shotgun approach.
-*/
-   list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+
+   drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+   drm_connector_list_iter_begin(dev, &conn_iter);
+   drm_for_each_connector_iter(connector, &conn_iter) {
vbox_conn = to_vbox_connector(connector);
 
hints = &vbox->last_mode_hints[vbox_conn->vbox_crtc->crtc_id];
@@ -157,7 +155,8 @@ static void vbox_update_mode_hints(struct vbox_private 
*vbox)
 
vbox_conn->vbox_crtc->disconnected = disconnected;
}
-   drm_modeset_unlock_all(dev);
+   drm_connector_list_iter_end(&conn_iter);
+   drm_modeset_unlock(&dev->mode_config.connection_mutex);
 }
 
 static void vbox_hotplug_worker(struct work_struct *work)
-- 
2.20.1

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