Re: [PATCH v3, 1/8] soc: mediatek: mmsys: create mmsys folder

2020-12-30 Thread Nicolas Boichat
On Mon, Dec 28, 2020 at 4:38 PM Yongqiang Niu
 wrote:
>
> the mmsys will more and more complicated after support
> more and more SoCs, add an independent folder will be
> more clear
>
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/soc/mediatek/Makefile  |   2 +-
>  drivers/soc/mediatek/mmsys/Makefile|   2 +
>  drivers/soc/mediatek/mmsys/mtk-mmsys.c | 380 
> +
>  drivers/soc/mediatek/mtk-mmsys.c   | 380 
> -

I wonder why this doesn't get detected as a rename?

>  4 files changed, 383 insertions(+), 381 deletions(-)
>  create mode 100644 drivers/soc/mediatek/mmsys/Makefile
>  create mode 100644 drivers/soc/mediatek/mmsys/mtk-mmsys.c
>  delete mode 100644 drivers/soc/mediatek/mtk-mmsys.c
>
> diff --git a/drivers/soc/mediatek/Makefile b/drivers/soc/mediatek/Makefile
> index 01f9f87..b5987ca 100644
> --- a/drivers/soc/mediatek/Makefile
> +++ b/drivers/soc/mediatek/Makefile
> @@ -3,4 +3,4 @@ obj-$(CONFIG_MTK_CMDQ) += mtk-cmdq-helper.o
>  obj-$(CONFIG_MTK_INFRACFG) += mtk-infracfg.o
>  obj-$(CONFIG_MTK_PMIC_WRAP) += mtk-pmic-wrap.o
>  obj-$(CONFIG_MTK_SCPSYS) += mtk-scpsys.o
> -obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> +obj-$(CONFIG_MTK_MMSYS) += mmsys/
> diff --git a/drivers/soc/mediatek/mmsys/Makefile 
> b/drivers/soc/mediatek/mmsys/Makefile
> new file mode 100644
> index 000..5d976d7
> --- /dev/null
> +++ b/drivers/soc/mediatek/mmsys/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o
> \ No newline at end of file

Nit: newline at end of file please.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [bug] Radeon 3900XT not switch to graphic mode on kernel 5.10

2020-12-30 Thread Mikhail Gavrilov
On Tue, 29 Dec 2020 at 20:15, Deucher, Alexander
 wrote:
>
> It looks like the driver is not able to access the firmware for some reason.  
> Please make sure it is available in your initrd or compiled into the kernel 
> depending on your config.

Exactly! Thanks!

# lsinitrd 
/boot/initramfs-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64.img
| grep sienna_cichlid

# ls /usr/lib/firmware/amdgpu | grep sienna_cichlid
sienna_cichlid_ce.bin
sienna_cichlid_dmcub.bin
sienna_cichlid_me.bin
sienna_cichlid_mec2.bin
sienna_cichlid_mec.bin
sienna_cichlid_pfp.bin
sienna_cichlid_rlc.bin
sienna_cichlid_sdma.bin
sienna_cichlid_smc.bin
sienna_cichlid_sos.bin
sienna_cichlid_ta.bin
sienna_cichlid_vcn.bin

# dracut -f --regenerate-all

# lsinitrd 
/boot/initramfs-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64.img
| grep sienna_cichlid
-rw-r--r--   1 root root   263296 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_ce.bin
-rw-r--r--   1 root root80244 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_dmcub.bin
-rw-r--r--   1 root root   263424 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_me.bin
-rw-r--r--   2 root root   268592 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_mec2.bin
-rw-r--r--   2 root root0 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_mec.bin
-rw-r--r--   1 root root   263424 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_pfp.bin
-rw-r--r--   1 root root   128592 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_rlc.bin
-rw-r--r--   1 root root34048 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_sdma.bin
-rw-r--r--   1 root root   247396 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_smc.bin
-rw-r--r--   1 root root   215152 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_sos.bin
-rw-r--r--   1 root root   333568 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_ta.bin
-rw-r--r--   1 root root   504224 Dec 15 14:00
usr/lib/firmware/amdgpu/sienna_cichlid_vcn.bin

# grep '20201204git34816d20f173\|linux-firmware-20201218-116'
/var/log/dnf.rpm.log
2020-12-06T12:40:44+0500 SUBDEBUG Installed:
kernel-core-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64
2020-12-06T12:40:46+0500 SUBDEBUG Installed:
kernel-modules-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64
2020-12-06T12:41:03+0500 SUBDEBUG Installed:
kernel-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64
2020-12-06T12:41:03+0500 SUBDEBUG Installed:
kernel-modules-extra-5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64
2020-12-21T10:52:43+0500 SUBDEBUG Upgrade:
linux-firmware-20201218-116.fc34.noarch

I think every update of linux-firmware should regenerate initramfs.
But my downstream report was closed:
https://bugzilla.redhat.com/show_bug.cgi?id=1911745

--
Best Regards,
Mike Gavrilov.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 210849] Black screen after resume from long suspend. Open/Close lid. AMDGPU

2020-12-30 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=210849

--- Comment #7 from JerryD (jvdeli...@charter.net) ---
[  296.606452] PM: resume devices took 10.437 seconds
[  296.606454] [ cut here ]
[  296.606455] Component: resume devices, time: 10437
[  296.606465] WARNING: CPU: 2 PID: 3357 at kernel/power/suspend_test.c:53
suspend_test_finish+0x74/0x80
[  296.606465] Modules linked in: ccm uinput rfcomm nf_conntrack_netlink
xt_CHECKSUM xt_addrtype xt_MASQUERADE xt_conntrack br_netfilter ipt_REJECT
nf_nat_tftp nf_conntrack_tftp tun bridge stp llc nft_objref
nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4
nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject
nft_ct nft_chain_nat nf_tables ebtable_nat ebtable_broute ip6table_nat
ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security
ip_set overlay nfnetlink ebtable_filter ebtables ip6table_filter ip6_tables
iptable_filter cmac bnep sunrpc vfat fat rtw88_8822be rtw88_8822b edac_mce_amd
kvm_amd rtw88_pci snd_hda_codec_realtek snd_hda_codec_hdmi rtw88_core
snd_hda_codec_generic ledtrig_audio kvm btusb snd_hda_intel btrtl
snd_intel_dspcfg btbcm btintel irqbypass snd_hda_codec uvcvideo rapl mac80211
videobuf2_vmalloc bluetooth hp_wmi snd_hda_core pcspkr
[  296.606504]  videobuf2_memops videobuf2_v4l2 snd_hwdep hid_sensor_accel_3d
wmi_bmof sparse_keymap snd_seq hid_sensor_rotation hid_sensor_magn_3d
videobuf2_common hid_sensor_gyro_3d snd_seq_device hid_sensor_incl_3d
hid_sensor_trigger snd_pcm videodev hid_sensor_iio_common
industrialio_triggered_buffer kfifo_buf ecdh_generic cfg80211 industrialio ecc
joydev snd_timer mc snd k10temp i2c_piix4 soundcore rfkill libarc4 hp_accel
i2c_scmi hp_wireless lis3lv02d acpi_cpufreq zram ip_tables mmc_block amdgpu
hid_sensor_hub hid_multitouch rtsx_pci_sdmmc mmc_core hid_logitech_hidpp
iommu_v2 gpu_sched i2c_algo_bit ttm drm_kms_helper cec crct10dif_pclmul drm
crc32_pclmul ccp crc32c_intel ghash_clmulni_intel serio_raw nvme rtsx_pci
nvme_core wmi video i2c_hid pinctrl_amd hid_logitech_dj fuse
[  296.606537] CPU: 2 PID: 3357 Comm: systemd-sleep Not tainted
5.9.16-200.fc33.x86_64 #1
[  296.606538] Hardware name: HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS
F.21 04/29/2019
[  296.606542] RIP: 0010:suspend_test_finish+0x74/0x80
[  296.606545] Code: e8 03 00 00 29 c1 e8 78 5d 9f 00 41 81 fc 10 27 00 00 77
04 5d 41 5c c3 44 89 e2 48 89 ee 48 c7 c7 c8 80 38 a8 e8 81 03 9f 00 <0f> 0b 5d
41 5c c3 cc cc cc cc cc cc 0f 1f 44 00 00 0f b6 05 58 d9
[  296.606546] RSP: 0018:bdf382e8fdd8 EFLAGS: 00010296
[  296.606548] RAX: 0026 RBX: 0001 RCX:
975857298d08
[  296.606549] RDX: ffd8 RSI: 0027 RDI:
975857298d00
[  296.606550] RBP: a8388011 R08: 00450f1f561c R09:
a9404be4
[  296.606551] R10: 058a R11: 00021ee0 R12:
28c5
[  296.606552] R13:  R14: bdf382e8fe08 R15:

[  296.606554] FS:  7f1e3fd5f000() GS:97585728()
knlGS:
[  296.606555] CS:  0010 DS:  ES:  CR0: 80050033
[  296.606556] CR2: 5584bb97e928 CR3: 00018e8f6000 CR4:
003506e0
[  296.606557] Call Trace:
[  296.606564]  suspend_devices_and_enter+0x1a2/0x7f0
[  296.606569]  pm_suspend.cold+0x329/0x374
[  296.606572]  state_store+0x71/0xd0
[  296.606577]  kernfs_fop_write+0xce/0x1b0
[  296.606581]  vfs_write+0xc7/0x210
[  296.606584]  ksys_write+0x4f/0xc0
[  296.606587]  do_syscall_64+0x33/0x40
[  296.606591]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  296.606593] RIP: 0033:0x7f1e40d26297
[  296.606597] Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00
f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00
f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24
[  296.606598] RSP: 002b:7ffe985f7fa8 EFLAGS: 0246 ORIG_RAX:
0001
[  296.606600] RAX: ffda RBX: 0007 RCX:
7f1e40d26297
[  296.606601] RDX: 0007 RSI: 5584bb97d920 RDI:
0004
[  296.606601] RBP: 5584bb97d920 R08: 0001 R09:
7f1e40df8a60
[  296.606602] R10: 0070 R11: 0246 R12:
0007
[  296.606603] R13: 5584bb978650 R14: 0007 R15:
7f1e40df9720
[  296.606605] ---[ end trace 6fa811f71ae3a8ac ]---

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

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


[PATCH libdrm] tests/util: Add mxsfb-drm driver

2020-12-30 Thread Fabio Estevam
Add an entry for the "mxsfb-drm" driver, so that the test utilities
work with the mxsfb driver without passing the -M argument.

Signed-off-by: Fabio Estevam 
---
 tests/util/kms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/util/kms.c b/tests/util/kms.c
index 08b48fe585b7..39a93866a9d1 100644
--- a/tests/util/kms.c
+++ b/tests/util/kms.c
@@ -149,6 +149,7 @@ static const char * const modules[] = {
"armada-drm",
"komeda",
"imx-dcss",
+   "mxsfb-drm",
 };
 
 int util_open(const char *device, const char *module)
-- 
2.17.1

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


Re: [PATCH] i915: fix shift warning

2020-12-30 Thread Chris Wilson
Quoting Arnd Bergmann (2020-12-30 15:39:14)
> From: Arnd Bergmann 
> 
> Randconfig builds on 32-bit machines show lots of warnings for
> the i915 driver for incorrect bit masks like:

mask is a u8.

VCS0 is 2, I915_MAX_VCS 4

(u8 & GENMASK(5, 2)) >> 2

> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2584:9: error: shift count >= 
> width of type [-Werror,-Wshift-count-overflow]
> return hweight64(VDBOX_MASK(>gt));
>^~~~
> include/asm-generic/bitops/const_hweight.h:29:49: note: expanded from macro 
> 'hweight64'
>  #define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) : 
> __arch_hweight64(w))

So it's upset by hweight64() on the unsigned long?
So hweight_long?

Or use a cast, hweight8((intel_engine_mask_t)VDMASK())?

static __always_inline int engine_count(intel_engine_mask_t mask)
{
return sizeof(mask) == 1 ? hweight8(mask) :
sizeof(mask) == 2 ? hweight16(mask) :
sizeof(mask) == 4 ? hweight32(mask) :
hweight64(mask);
}
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

2020-12-30 Thread Ilia Mirkin
On Wed, Dec 30, 2020 at 6:08 AM Chenyang Li  wrote:
> +   switch (format->format) {
> +   case DRM_FORMAT_RGB565:
> +   lcrtc->cfg_reg |= 0x3;
> +   break;
> +   case DRM_FORMAT_RGB888:
> +   default:
> +   lcrtc->cfg_reg |= 0x4;
> +   break;
> +   }

How does the scanout engine distinguish between RGB888 (24-bit) and
XRGB (32-bit)? You've listed both as supported below.

Cheers,

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


[PATCH] i915: fix shift warning

2020-12-30 Thread Arnd Bergmann
From: Arnd Bergmann 

Randconfig builds on 32-bit machines show lots of warnings for
the i915 driver for incorrect bit masks like:

drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2584:9: error: shift count >= 
width of type [-Werror,-Wshift-count-overflow]
return hweight64(VDBOX_MASK(>gt));
   ^~~~
include/asm-generic/bitops/const_hweight.h:29:49: note: expanded from macro 
'hweight64'
 #define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) : 
__arch_hweight64(w))

Since this is a 64-bit mask, use GENMASK_ULL instead of GENMASK.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0a3ee4f9dc0a..ca32fa0d6a57 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1624,7 +1624,7 @@ tgl_revids_get(struct drm_i915_private *dev_priv)
unsigned int first__ = (first); \
unsigned int count__ = (count); \
((gt)->info.engine_mask &   
\
-GENMASK(first__ + count__ - 1, first__)) >> first__;   \
+GENMASK_ULL(first__ + count__ - 1, first__)) >> first__;   
\
 })
 #define VDBOX_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, VCS0, I915_MAX_VCS)
-- 
2.29.2

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


[PATCH AUTOSEL 5.10 23/31] drm/amd/display: updated wm table for Renoir

2020-12-30 Thread Sasha Levin
From: Jake Wang 

[ Upstream commit 410066d24cfc1071be25e402510367aca9db5cb6 ]

[Why]
For certain timings, Renoir may underflow due to sr exit
latency being too slow.

[How]
Updated wm table for renoir.

Signed-off-by: Jake Wang 
Reviewed-by: Yongqiang Sun 
Acked-by: Qingqing Zhuo 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c| 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
index 6b431db146cd9..1c6e401dd4cce 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -704,24 +704,24 @@ static struct wm_table ddr4_wm_table_rn = {
.wm_inst = WM_B,
.wm_type = WM_TYPE_PSTATE_CHG,
.pstate_latency_us = 11.72,
-   .sr_exit_time_us = 10.12,
-   .sr_enter_plus_exit_time_us = 11.48,
+   .sr_exit_time_us = 11.12,
+   .sr_enter_plus_exit_time_us = 12.48,
.valid = true,
},
{
.wm_inst = WM_C,
.wm_type = WM_TYPE_PSTATE_CHG,
.pstate_latency_us = 11.72,
-   .sr_exit_time_us = 10.12,
-   .sr_enter_plus_exit_time_us = 11.48,
+   .sr_exit_time_us = 11.12,
+   .sr_enter_plus_exit_time_us = 12.48,
.valid = true,
},
{
.wm_inst = WM_D,
.wm_type = WM_TYPE_PSTATE_CHG,
.pstate_latency_us = 11.72,
-   .sr_exit_time_us = 10.12,
-   .sr_enter_plus_exit_time_us = 11.48,
+   .sr_exit_time_us = 11.12,
+   .sr_enter_plus_exit_time_us = 12.48,
.valid = true,
},
}
-- 
2.27.0

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


Re: [PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()

2020-12-30 Thread Viresh Kumar
On 28-12-20, 17:03, Dmitry Osipenko wrote:
> 28.12.2020 09:22, Viresh Kumar пишет:
> > On 24-12-20, 16:00, Dmitry Osipenko wrote:
> >> In a device driver I want to set PD to the lowest performance state by
> >> removing the performance vote when dev_pm_opp_set_rate(dev, 0) is
> >> invoked by the driver.
> >>
> >> The OPP core already does this, but if OPP levels don't start from 0 in
> >> a device-tree for PD, then it currently doesn't work since there is a
> >> need to get a rounded-up performance state because
> >> dev_pm_opp_set_voltage() takes OPP entry for the argument (patches 9 and
> >> 28).
> >>
> >> The PD powering off and performance-changes are separate from each other
> >> in the GENPD core. The GENPD core automatically turns off domain when
> >> all devices within the domain are suspended by system-suspend or RPM.
> >>
> >> The performance state of a power domain is controlled solely by a device
> >> driver. GENPD core only aggregates the performance requests, it doesn't
> >> change the performance state of a domain by itself when device is
> >> suspended or resumed, IIUC this is intentional. And I want to put domain
> >> into lowest performance state when device is suspended.
> > 
> > Right, so if you really want to just drop the performance vote, then with a
> > value of 0 for the performance state the call will reach to your genpd's
> > callback ->set_performance_state(). Just as dev_pm_opp_set_rate() accepts 
> > the
> > frequency to be 0, I would expect dev_pm_opp_set_rate() to accept opp 
> > argument
> > as NULL and in that case set voltage to 0 and do regulator_disable() as 
> > well.
> > Won't that work better than going for the lowest voltage ?
> > 
> 
> We can make dev_pm_opp_set_voltage() to accept OPP=NULL in order to
> disable the regulator, like it's done for dev_pm_opp_set_rate(dev, 0).
> Although, I don't need this kind of behaviour for the Tegra PD driver,
> and thus, would prefer to leave this for somebody else to implement in
> the future, once it will be really needed.
> 
> Still we need the dev_pm_opp_find_level_ceil() because level=0 means
> that we want to set PD to the lowest (minimal) performance state, i.e.
> it doesn't necessarily mean that we want to set the voltage to 0 and
> disable the PD entirely. GENPD has a separate controls for on/off.

Ok.

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


[PATCH] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

2020-12-30 Thread Chenyang Li
This patch adds an initial DRM driver for the Loongson LS7A1000
bridge chip(LS7A). The LS7A bridge chip contains two display
controllers, support dual display output. The maximum support for
each channel display is to 1920x1080@60Hz.
At present, DC device detection and DRM driver registration are
completed, the crtc/plane/encoder/connector objects has been
implemented.
On Loongson 3A4000 CPU and 7A1000 system, we have achieved the use
of dual screen, and support dual screen clone mode and expansion
mode.

Signed-off-by: Chenyang Li 
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/loongson/Kconfig  |  14 +
 drivers/gpu/drm/loongson/Makefile |  14 +
 drivers/gpu/drm/loongson/loongson_connector.c |  48 
 drivers/gpu/drm/loongson/loongson_crtc.c  | 247 
 drivers/gpu/drm/loongson/loongson_device.c|  54 
 drivers/gpu/drm/loongson/loongson_drv.c   | 269 ++
 drivers/gpu/drm/loongson/loongson_drv.h   | 133 +
 drivers/gpu/drm/loongson/loongson_encoder.c   |  37 +++
 drivers/gpu/drm/loongson/loongson_plane.c | 102 +++
 11 files changed, 921 insertions(+)
 create mode 100644 drivers/gpu/drm/loongson/Kconfig
 create mode 100644 drivers/gpu/drm/loongson/Makefile
 create mode 100644 drivers/gpu/drm/loongson/loongson_connector.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_crtc.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_device.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_drv.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_drv.h
 create mode 100644 drivers/gpu/drm/loongson/loongson_encoder.c
 create mode 100644 drivers/gpu/drm/loongson/loongson_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 0973f408d75f..6ed1b6dc2f25 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -374,6 +374,8 @@ source "drivers/gpu/drm/xen/Kconfig"
 
 source "drivers/gpu/drm/vboxvideo/Kconfig"
 
+source "drivers/gpu/drm/loongson/Kconfig"
+
 source "drivers/gpu/drm/lima/Kconfig"
 
 source "drivers/gpu/drm/panfrost/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index fefaff4c832d..f87da730ea6d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -119,6 +119,7 @@ obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
 obj-$(CONFIG_DRM_XEN) += xen/
 obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/
+obj-$(CONFIG_DRM_LOONGSON) += loongson/
 obj-$(CONFIG_DRM_LIMA)  += lima/
 obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
diff --git a/drivers/gpu/drm/loongson/Kconfig b/drivers/gpu/drm/loongson/Kconfig
new file mode 100644
index ..43eb0c80cc12
--- /dev/null
+++ b/drivers/gpu/drm/loongson/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config DRM_LOONGSON
+   tristate "DRM support for LS7A1000 bridge chipset"
+   depends on DRM && PCI
+   depends on CPU_LOONGSON64
+   select DRM_KMS_HELPER
+   select DRM_VRAM_HELPER
+   select DRM_TTM
+   select DRM_TTM_HELPER
+   default n
+   help
+ Support the display controllers found on the Loongson LS7A1000
+ bridge.
diff --git a/drivers/gpu/drm/loongson/Makefile 
b/drivers/gpu/drm/loongson/Makefile
new file mode 100644
index ..22d063953b78
--- /dev/null
+++ b/drivers/gpu/drm/loongson/Makefile
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Makefile for loongson drm drivers.
+# This driver provides support for the
+# Direct Rendering Infrastructure (DRI)
+
+ccflags-y := -Iinclude/drm
+loongson-y := loongson_drv.o \
+   loongson_crtc.o \
+   loongson_plane.o \
+   loongson_device.o \
+   loongson_connector.o \
+   loongson_encoder.o
+obj-$(CONFIG_DRM_LOONGSON) += loongson.o
diff --git a/drivers/gpu/drm/loongson/loongson_connector.c 
b/drivers/gpu/drm/loongson/loongson_connector.c
new file mode 100644
index ..6b1f0ffa33bd
--- /dev/null
+++ b/drivers/gpu/drm/loongson/loongson_connector.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include "loongson_drv.h"
+
+static int loongson_get_modes(struct drm_connector *connector)
+{
+   int count;
+
+   count = drm_add_modes_noedid(connector, 1920, 1080);
+   drm_set_preferred_mode(connector, 1024, 768);
+
+   return count;
+}
+
+static const struct drm_connector_helper_funcs loongson_connector_helper = {
+   .get_modes = loongson_get_modes,
+};
+
+static const struct drm_connector_funcs loongson_connector_funcs = {
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy = drm_connector_cleanup,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+int 

Re: [PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting

2020-12-30 Thread Xin Ji
On Tue, Dec 29, 2020 at 04:34:20PM +0200, Laurent Pinchart wrote:
> Hi Xin Ji,
> 
> On Tue, Dec 29, 2020 at 02:50:48PM +0800, Xin Ji wrote:
> > On Mon, Dec 28, 2020 at 05:08:56PM +0200, Laurent Pinchart wrote:
> > > On Fri, Dec 25, 2020 at 07:01:09PM +0800, Xin Ji wrote:
> > > > Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add
> > > > swing setting for adjusting DP tx PHY swing
> > > > 
> > > > Signed-off-by: Xin Ji 
> > > > ---
> > > >  .../bindings/display/bridge/analogix,anx7625.yaml | 19 
> > > > +++
> > > >  1 file changed, 19 insertions(+)
> > > > 
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > >  
> > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > index 60585a4..34a7faf 100644
> > > > --- 
> > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > +++ 
> > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > @@ -34,6 +34,14 @@ properties:
> > > >  description: used for reset chip control, RESET_N pin B7.
> > > >  maxItems: 1
> > > >  
> > > > +  anx,swing-setting:
> > > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > > > +description: an array of swing register setting for DP tx PHY
> > > 
> > > Register values in DT are frowned upon.
> >
> > Hi Laurent Pinchart, as the different vendor has the different PCB layout,
> > it effects DP CTS test result, so they may need config DP tx Swing register
> > to adjust signal swing(the default swing setting is not satisfy for
> > every platform). If we move the config code to driver file, it must define
> > swing register setting for each vendor, so the DT is the best way. Do you
> > have any idea for it if you don't agree to add in DT.
> 
> If it depends on the PCB layout then it should indeed be in DT. What I
> wonder is if there would be a better way to specify the data than
> register values. The ANX7625 datasheet isn't public, so there's
> effectively no way for someone to write a device tree compliant with
> this binding only with the information contained here. Reviewing the
> bindings is equally difficult. It would be best if this property instead
> contained information that could be documented clearly.
Hi Laurent Pinchart, the swing register setting is optional. Basically, no need
to care about it if customer PCB layout match our chip requirement. The
property define just in case. So far, we just found one customer encountered
DP tx swing issue. As the datasheet swing register adjusting algorithm
has a little complex, we will help customer to adjust the DP tx swing
case by case.
> 
> > > > +  anx,mipi-dpi-in:
> > > > +$ref: /schemas/types.yaml#/definitions/uint32
> > > > +description: indicate the MIPI rx signal type is DPI or DSI
> > > 
> > > This sounds similar to the bus-type property defined in
> > > Documentation/devicetree/bindings/media/video-interfaces.txt (which is
> > > getting converted to YAML, Rob has posted a patch series, I expect it to
> > > land in v5.13). I think it would make sense to extend bus-type to
> > > support DSI, and use that property.
> >
> > Sorry, I didn't found any define for DPI or DSI flag in Rob's patches.
> > Do you mean I just remove this flag define and call a special function
> > to read the port's type(DSI or DPI)?
> 
> video-interfaces.yaml has initially been written for cameras, so it
> doesn't support DSI. I think it would make sense to extend the bus-type
> property with a DSI type, and use it here instead of a vendor-specific
> property.
> 
> Alternatively, I'm wondering if this isn't information we could query at
> runtime. DRM bridges and panels have a type, so we could look at the
> next bridge or panel to find the type of the connected device instead of
> specifying it in DT.

At anx7625 driver probe stage, for the DSI, driver needs call some special
interface to attach to DSI interface. For the DPI port, there is no such
limitation, so we need to know what kind of MIPI signal type at driver initial
stage.
Maybe we can keep this flag, if the future has defined DSI, I'll submit new
patch to remove this flag.

Thanks,
Xin

> 
> > > > +
> > > >ports:
> > > >  type: object
> > > >  
> > > > @@ -72,6 +80,17 @@ examples:
> > > >  reg = <0x58>;
> > > >  enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
> > > >  reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
> > > > +anx,swing-setting = <0x00 0x14>, <0x01 0x54>,
> > > > +<0x02 0x64>, <0x03 0x74>, <0x04 0x29>,
> > > > +<0x05 0x7b>, <0x06 0x77>, <0x07 0x5b>,
> > > > +<0x08 0x7f>, <0x0c 0x20>, <0x0d 0x60>,
> > > > +<0x10 0x60>, <0x12 0x40>, <0x13 0x60>,
> > > > +<0x14 0x14>, <0x15 0x54>, <0x16 0x64>,
> > > > +<0x17 0x74>, <0x18 0x29>, <0x19 0x7b>,
> > > > +<0x1a 0x77>, <0x1b 0x5b>, 

[PATCH] drm/tve200: remove unused including

2020-12-30 Thread Tian Tao
Remove including  that don't need it.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/tve200/tve200_display.c | 1 -
 drivers/gpu/drm/tve200/tve200_drv.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/tve200/tve200_display.c 
b/drivers/gpu/drm/tve200/tve200_display.c
index 17ff24d..cb0e837 100644
--- a/drivers/gpu/drm/tve200/tve200_display.c
+++ b/drivers/gpu/drm/tve200/tve200_display.c
@@ -11,7 +11,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/tve200/tve200_drv.c 
b/drivers/gpu/drm/tve200/tve200_drv.c
index 07140e0..7fa71c8 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
-- 
2.7.4

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


[PATCH] drm/pl111: remove unused including

2020-12-30 Thread Tian Tao
Remove including  that don't need it.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/pl111/pl111_display.c | 1 -
 drivers/gpu/drm/pl111/pl111_drv.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 69c02e7..e8376ae 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -11,7 +11,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index e4dcaef..4aad9eb 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -44,7 +44,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
-- 
2.7.4

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


[PATCH -next] drm/i915: Use kzalloc for allocating only one thing

2020-12-30 Thread Zheng Yongjun
Use kzalloc rather than kcalloc(1,...)

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
@@

- kcalloc(1,
+ kzalloc(
  ...)
// 

Signed-off-by: Zheng Yongjun 
---
 drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index f88473d396f4..6994b167d0c8 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -415,7 +415,7 @@ static int igt_evict_contexts(void *arg)
struct reserved *r;
 
mutex_unlock(>vm.mutex);
-   r = kcalloc(1, sizeof(*r), GFP_KERNEL);
+   r = kzalloc(sizeof(*r), GFP_KERNEL);
mutex_lock(>vm.mutex);
if (!r) {
err = -ENOMEM;
-- 
2.22.0

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


Re: [PATCH] drm/tve200: remove unused including

2020-12-30 Thread Linus Walleij
On Wed, Dec 30, 2020 at 2:17 AM Tian Tao  wrote:

> Remove including  that don't need it.
>
> Signed-off-by: Tian Tao 

Patch applied.

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