[linux-next:master] BUILD REGRESSION 0f067394dd3b2af3263339cf7183bdb6ee0ac1f8
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 0f067394dd3b2af3263339cf7183bdb6ee0ac1f8 Add linux-next specific
files for 20240109
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202401101414.8gvbgmxw-...@intel.com
Error/Warning: (recently discovered and may have been fixed)
drivers/net/ethernet/wangxun/libwx/wx_ethtool.c:193:(.text+0x2cc): undefined
reference to `phylink_ethtool_nway_reset'
drivers/net/ethernet/wangxun/libwx/wx_ethtool.c:202:(.text+0x2f0): undefined
reference to `phylink_ethtool_ksettings_get'
drivers/net/ethernet/wangxun/libwx/wx_ethtool.c:211:(.text+0x318): undefined
reference to `phylink_ethtool_ksettings_set'
tools/testing/selftests/net/tcp_ao/bench-lookups.c:202: undefined reference to
`sqrt'
Unverified Error/Warning (likely false positive, please contact us if
interested):
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (120b92 becomes b92)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (1a069a becomes 69a)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (1b001b becomes 1b)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (1b009b becomes 9b)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (1b011b becomes 11b)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (1b039b becomes 39b)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (1b049b becomes 49b)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (1b051b becomes 51b)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (1b059b becomes 59b)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (80a08 becomes a08)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (80d08 becomes d08)
arch/x86/kvm/vmx/hyperv_evmcs.h:133:30: sparse: sparse: cast truncates bits
from constant value (b000b becomes b)
drivers/usb/gadget/function/f_ncm.c:1688:32: sparse: sparse: incorrect type in
assignment (different base types)
{standard input}:50469: Warning: overflow in branch to .L4505; converted into
longer instruction sequence
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-dst_addr-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-filled_descs_num-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-size-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-src_addr-not-described-in-xdma_fill_descs
| `--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-sw_desc-not-described-in-xdma_fill_descs
|-- arc-allmodconfig
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-dst_addr-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-filled_descs_num-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-size-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-src_addr-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-sw_desc-not-described-in-xdma_fill_descs
| `--
drivers-gpu-drm-msm-disp-dpu1-dpu_encoder.c:warning:Excess-struct-member-debugfs_root-description-in-dpu_encoder_virt
|-- arc-allyesconfig
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-dst_addr-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-filled_descs_num-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-size-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-src_addr-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-sw_desc-not-described-in-xdma_fill_descs
| `--
drivers-gpu-drm-msm-disp-dpu1-dpu_encoder.c:warning:Excess-struct-member-debugfs_root-description-in-dpu_encoder_virt
|-- arc-randconfig-001-20240109
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-dst_addr-not-described-in-xdma_fill_descs
| |--
drivers-dma-xilinx-xdma.c:warning:Function-parameter-or-struct-member-filled_descs_num-not-described
Re: [DO NOT MERGE v6 27/37] dt-bindings: ata: ata-generic: Add new targets
On 1/10/24 16:19, Krzysztof Kozlowski wrote: > On 10/01/2024 03:06, Damien Le Moal wrote: >> On 1/9/24 17:23, Yoshinori Sato wrote: >>> Added new ata-generic target. >>> - iodata,usl-5p-ata >>> - renesas,rts7751r2d-ata >>> >>> Each boards have simple IDE Interface. Use ATA generic driver. >> >> This looks OK to me, so feel free to add: >> >> Acked-by: Damien Le Moal >> >> Note: The "DO NOT MERGE" patch prefix almost got me to immediately delete >> this >> 37 patches in my inbox... If you wish to get this work merged after review, >> please use the regular "PATCH" prefix. No worries, the series will not be >> merged >> until is is reviewed :) > > The point of DO NOT MERGE was that feedback was not being implemented > and same set of patches with same issues were kept sending. :/ OK. I found that prefix unusual, but not a big deal. Thanks. > > Best regards, > Krzysztof > -- Damien Le Moal Western Digital Research
Re: [DO NOT MERGE v6 27/37] dt-bindings: ata: ata-generic: Add new targets
On 10/01/2024 03:06, Damien Le Moal wrote: > On 1/9/24 17:23, Yoshinori Sato wrote: >> Added new ata-generic target. >> - iodata,usl-5p-ata >> - renesas,rts7751r2d-ata >> >> Each boards have simple IDE Interface. Use ATA generic driver. > > This looks OK to me, so feel free to add: > > Acked-by: Damien Le Moal > > Note: The "DO NOT MERGE" patch prefix almost got me to immediately delete this > 37 patches in my inbox... If you wish to get this work merged after review, > please use the regular "PATCH" prefix. No worries, the series will not be > merged > until is is reviewed :) The point of DO NOT MERGE was that feedback was not being implemented and same set of patches with same issues were kept sending. :/ Best regards, Krzysztof
Re: [PATCH v2 2/2] drm/imx/dcss: have all init functions use devres
Hi Philipp,
kernel test robot noticed the following build errors:
[auto build test ERROR on v6.7]
[also build test ERROR on linus/master]
[cannot apply to drm-misc/drm-misc-next next-20240109]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Philipp-Stanner/drm-dcss-request-memory-region/20240109-182239
base: v6.7
patch link:
https://lore.kernel.org/r/20240109102032.16165-3-pstanner%40redhat.com
patch subject: [PATCH v2 2/2] drm/imx/dcss: have all init functions use devres
config: arm64-defconfig
(https://download.01.org/0day-ci/archive/20240110/202401101401.bi7u74fr-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240110/202401101401.bi7u74fr-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202401101401.bi7u74fr-...@intel.com/
All error/warnings (new ones prefixed by >>):
In file included from include/linux/device.h:17,
from include/linux/platform_device.h:13,
from drivers/gpu/drm/imx/dcss/dcss-dev.c:9:
drivers/gpu/drm/imx/dcss/dcss-dev.c: In function 'dcss_dev_create':
drivers/gpu/drm/imx/dcss/dcss-dev.c:186:42: error: incompatible type for
argument 1 of '__devm_request_region'
186 | if (!devm_request_mem_region(pdev->dev, res->start, res_len,
"dcss")) {
| ^
| |
| struct device
include/linux/ioport.h:306:31: note: in definition of macro
'devm_request_mem_region'
306 | __devm_request_region(dev, _resource, (start), (n),
(name))
| ^~~
include/linux/ioport.h:308:63: note: expected 'struct device *' but argument
is of type 'struct device'
308 | extern struct resource * __devm_request_region(struct device *dev,
|~~~^~~
>> drivers/gpu/drm/imx/dcss/dcss-dev.c:202:24: warning: returning 'int' from a
>> function with return type 'struct dcss_dev *' makes pointer from integer
>> without a cast [-Wint-conversion]
202 | return ret;
|^~~
--
drivers/gpu/drm/imx/dcss/dcss-scaler.c: In function
'dcss_scaler_ch_init_all':
>> drivers/gpu/drm/imx/dcss/dcss-scaler.c:305:45: error: 'dev' undeclared
>> (first use in this function); did you mean 'cdev'?
305 | ch->base_reg = devm_ioremap(dev, ch->base_ofs,
SZ_4K);
| ^~~
| cdev
drivers/gpu/drm/imx/dcss/dcss-scaler.c:305:45: note: each undeclared
identifier is reported only once for each function it appears in
drivers/gpu/drm/imx/dcss/dcss-scaler.c: In function 'dcss_scaler_init':
>> drivers/gpu/drm/imx/dcss/dcss-scaler.c:331:37: error: passing argument 1 of
>> 'dcss_scaler_ch_init_all' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
331 | if (dcss_scaler_ch_init_all(dev, scaler, scaler_base))
| ^~~
| |
| struct device *
drivers/gpu/drm/imx/dcss/dcss-scaler.c:294:56: note: expected 'struct
dcss_scaler *' but argument is of type 'struct device *'
294 | static int dcss_scaler_ch_init_all(struct dcss_scaler *scl,
|^~~
>> drivers/gpu/drm/imx/dcss/dcss-scaler.c:331:42: warning: passing argument 2
>> of 'dcss_scaler_ch_init_all' makes integer from pointer without a cast
>> [-Wint-conversion]
331 | if (dcss_scaler_ch_init_all(dev, scaler, scaler_base))
| ^~
| |
| struct dcss_scaler *
drivers/gpu/drm/imx/dcss/dcss-scaler.c:295:50: note: expected 'long unsigned
int' but argument is of type 'struct dcss_scaler *'
295 |unsigned long scaler_base)
|~~^~~
>> drivers/gpu/drm/imx/dcss/dcss-scaler.c:331:13: error: too many arguments to
>> function 'dcss_scaler_ch_init_all'
331 | if (dcss_scaler_ch_init_all(dev, scaler, sca
[PATCH v2] drm: Check output polling initialized before disabling
In drm_kms_helper_poll_disable() check if output polling support is initialized before disabling polling. For drivers like hyperv-drm, that do not initialize connector polling, if suspend is called without this check, it leads to suspend failure with following stack [ 770.719392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 770.720592] printk: Suspending console(s) (use no_console_suspend to debug) [ 770.948823] [ cut here ] [ 770.948824] WARNING: CPU: 1 PID: 17197 at kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230 [ 770.948831] Modules linked in: rfkill nft_counter xt_conntrack xt_owner udf nft_compat crc_itu_t 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_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vfat fat mlx5_ib ib_uverbs ib_core mlx5_core intel_rapl_msr intel_rapl_common kvm_amd ccp mlxfw kvm psample hyperv_drm tls drm_shmem_helper drm_kms_helper irqbypass pcspkr syscopyarea sysfillrect sysimgblt hv_balloon hv_utils joydev drm fuse xfs libcrc32c pci_hyperv pci_hyperv_intf sr_mod sd_mod cdrom t10_pi sg hv_storvsc scsi_transport_fc hv_netvsc serio_raw hyperv_keyboard hid_hyperv crct10dif_pclmul crc32_pclmul crc32c_intel hv_vmbus ghash_clmulni_intel dm_mirror dm_region_hash dm_log dm_mod [ 770.948863] CPU: 1 PID: 17197 Comm: systemd-sleep Not tainted 5.14.0-362.2.1.el9_3.x86_64 #1 [ 770.948865] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 770.948866] RIP: 0010:__flush_work.isra.0+0x212/0x230 [ 770.948869] Code: 8b 4d 00 4c 8b 45 08 89 ca 48 c1 e9 04 83 e2 08 83 e1 0f 83 ca 02 89 c8 48 0f ba 6d 00 03 e9 25 ff ff ff 0f 0b e9 4e ff ff ff <0f> 0b 45 31 ed e9 44 ff ff ff e8 8f 89 b2 00 66 66 2e 0f 1f 84 00 [ 770.948870] RSP: 0018:af4ac213fb10 EFLAGS: 00010246 [ 770.948871] RAX: RBX: RCX: 8c992857 [ 770.948872] RDX: 0001 RSI: 0001 RDI: 9aad82b00330 [ 770.948873] RBP: 9aad82b00330 R08: R09: 9aad87ee3d10 [ 770.948874] R10: 0200 R11: R12: 9aad82b00330 [ 770.948874] R13: 0001 R14: R15: 0001 [ 770.948875] FS: 7ff1b2f6bb40() GS:9aaf37d0() knlGS: [ 770.948878] CS: 0010 DS: ES: CR0: 80050033 [ 770.948878] CR2: 555f345cb666 CR3: 0001462dc005 CR4: 00370ee0 [ 770.948879] Call Trace: [ 770.948880] [ 770.948881] ? show_trace_log_lvl+0x1c4/0x2df [ 770.948884] ? show_trace_log_lvl+0x1c4/0x2df [ 770.948886] ? __cancel_work_timer+0x103/0x190 [ 770.948887] ? __flush_work.isra.0+0x212/0x230 [ 770.948889] ? __warn+0x81/0x110 [ 770.948891] ? __flush_work.isra.0+0x212/0x230 [ 770.948892] ? report_bug+0x10a/0x140 [ 770.948895] ? handle_bug+0x3c/0x70 [ 770.948898] ? exc_invalid_op+0x14/0x70 [ 770.948899] ? asm_exc_invalid_op+0x16/0x20 [ 770.948903] ? __flush_work.isra.0+0x212/0x230 [ 770.948905] __cancel_work_timer+0x103/0x190 [ 770.948907] ? _raw_spin_unlock_irqrestore+0xa/0x30 [ 770.948910] drm_kms_helper_poll_disable+0x1e/0x40 [drm_kms_helper] [ 770.948923] drm_mode_config_helper_suspend+0x1c/0x80 [drm_kms_helper] [ 770.948933] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus] [ 770.948942] hyperv_vmbus_suspend+0x17/0x40 [hyperv_drm] [ 770.948944] ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus] [ 770.948951] dpm_run_callback+0x4c/0x140 [ 770.948954] __device_suspend_noirq+0x74/0x220 [ 770.948956] dpm_noirq_suspend_devices+0x148/0x2a0 [ 770.948958] dpm_suspend_end+0x54/0xe0 [ 770.948960] create_image+0x14/0x290 [ 770.948963] hibernation_snapshot+0xd6/0x200 [ 770.948964] hibernate.cold+0x8b/0x1fb [ 770.948967] state_store+0xcd/0xd0 [ 770.948969] kernfs_fop_write_iter+0x124/0x1b0 [ 770.948973] new_sync_write+0xff/0x190 [ 770.948976] vfs_write+0x1ef/0x280 [ 770.948978] ksys_write+0x5f/0xe0 [ 770.948979] do_syscall_64+0x5c/0x90 [ 770.948981] ? syscall_exit_work+0x103/0x130 [ 770.948983] ? syscall_exit_to_user_mode+0x12/0x30 [ 770.948985] ? do_syscall_64+0x69/0x90 [ 770.948986] ? do_syscall_64+0x69/0x90 [ 770.948987] ? do_user_addr_fault+0x1d6/0x6a0 [ 770.948989] ? do_syscall_64+0x69/0x90 [ 770.948990] ? exc_page_fault+0x62/0x150 [ 770.948992] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 770.948995] RIP: 0033:0x7ff1b293eba7 [ 770.949010] Code: 0b 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 [ 770.949011] RSP: 002b:7ffde3912128 EFLAGS: 0246 ORIG_RAX: 0001 [ 770.949012] RAX: ffda RBX: 0005 RCX: 7ff1b293eba7 [ 770.949013] RDX: 0005 RSI:
Re: [PATCH] drm/v3d: Free the job and assign it to NULL if initialization fails
I think this is fine, but I was wondering if it would be simpler and
easier to just remove the sched cleanup from v3d_job_init and instead
always rely on callers to eventually call v3d_job_cleanup for fail
paths, where we are already calling v3d_job_cleanup.
Iago
El mar, 09-01-2024 a las 11:28 -0300, Maíra Canal escribió:
> Currently, if `v3d_job_init()` fails (e.g. in the IGT test "bad-in-
> sync",
> where we submit an invalid in-sync to the IOCTL), then we end up with
> the following NULL pointer dereference:
>
> [ 34.146279] Unable to handle kernel NULL pointer dereference at
> virtual address 0078
> [ 34.146301] Mem abort info:
> [ 34.146306] ESR = 0x9605
> [ 34.146315] EC = 0x25: DABT (current EL), IL = 32 bits
> [ 34.146322] SET = 0, FnV = 0
> [ 34.146328] EA = 0, S1PTW = 0
> [ 34.146334] FSC = 0x05: level 1 translation fault
> [ 34.146340] Data abort info:
> [ 34.146345] ISV = 0, ISS = 0x0005, ISS2 = 0x
> [ 34.146351] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
> [ 34.146357] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
> [ 34.146366] user pgtable: 4k pages, 39-bit VAs,
> pgdp=0001232e6000
> [ 34.146375] [0078] pgd=,
> p4d=, pud=
> [ 34.146399] Internal error: Oops: 9605 [#1] PREEMPT
> SMP
> [ 34.146406] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer
> snd_seq snd_seq_device algif_hash aes_neon_bs aes_neon_blk
> algif_skcipher af_alg bnep hid_logitech_hidpp brcmfmac_wcc brcmfmac
> brcmutil hci_uart vc4 btbcm cfg80211 bluetooth bcm2835_v4l2(C)
> snd_soc_hdmi_codec binfmt_misc cec drm_display_helper hid_logitech_dj
> bcm2835_mmal_vchiq(C) drm_dma_helper drm_kms_helper videobuf2_v4l2
> raspberrypi_hwmon ecdh_generic videobuf2_vmalloc videobuf2_memops ecc
> videobuf2_common rfkill videodev libaes snd_soc_core dwc2 i2c_brcmstb
> snd_pcm_dmaengine snd_bcm2835(C) i2c_bcm2835 pwm_bcm2835 snd_pcm mc
> v3d snd_timer snd gpu_sched drm_shmem_helper nvmem_rmem
> uio_pdrv_genirq uio i2c_dev drm fuse dm_mod
> drm_panel_orientation_quirks backlight configfs ip_tables x_tables
> ipv6
> [ 34.146556] CPU: 1 PID: 1890 Comm: v3d_submit_csd Tainted:
> G C 6.7.0-rc3-g49ddab089611 #68
> [ 34.146563] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
> [ 34.146569] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
> [ 34.146575] pc : drm_sched_job_cleanup+0x3c/0x190 [gpu_sched]
> [ 34.146611] lr : v3d_submit_csd_ioctl+0x1b4/0x460 [v3d]
> [ 34.146653] sp : ffc083cbbb80
> [ 34.146658] x29: ffc083cbbb90 x28: ff81035afc00 x27:
> ffe77a641168
> [ 34.146668] x26: ff81056a8000 x25: 0058 x24:
>
> [ 34.146677] x23: ff81065e2000 x22: ff81035afe00 x21:
> ffc083cbbcf0
> [ 34.146686] x20: ff81035afe00 x19: ffea x18:
>
> [ 34.146694] x17: x16: ffe7989e34b0 x15:
>
> [ 34.146703] x14: 0404 x13: ff81035afe80 x12:
> ffc083cb8000
> [ 34.146711] x11: cc57e05dfbe5ef00 x10: cc57e05dfbe5ef00 x9 :
> ffe77a64131c
> [ 34.146719] x8 : x7 : x6 :
> 003f
> [ 34.146727] x5 : 0040 x4 : ff81fefb03f0 x3 :
> ffc083cbba40
> [ 34.146736] x2 : ff81056a8000 x1 : ffe7989e35e8 x0 :
>
> [ 34.146745] Call trace:
> [ 34.146748] drm_sched_job_cleanup+0x3c/0x190 [gpu_sched]
> [ 34.146768] v3d_submit_csd_ioctl+0x1b4/0x460 [v3d]
> [ 34.146791] drm_ioctl_kernel+0xe0/0x120 [drm]
> [ 34.147029] drm_ioctl+0x264/0x408 [drm]
> [ 34.147135] __arm64_sys_ioctl+0x9c/0xe0
> [ 34.147152] invoke_syscall+0x4c/0x118
> [ 34.147162] el0_svc_common+0xb8/0xf0
> [ 34.147168] do_el0_svc+0x28/0x40
> [ 34.147174] el0_svc+0x38/0x88
> [ 34.147184] el0t_64_sync_handler+0x84/0x100
> [ 34.147191] el0t_64_sync+0x190/0x198
> [ 34.147201] Code: aa0003f4 f90007e8 f9401008 aa0803e0 (b8478c09)
> [ 34.147210] ---[ end trace ]---
>
> This happens because we are calling `drm_sched_job_cleanup()` twice:
> once at `v3d_job_init()` and again when we call `v3d_job_cleanup()`.
>
> To mitigate this issue, we can return to the same approach that we
> used
> to use before 464c61e76de8: deallocate the job after `v3d_job_init()`
> fails and assign it to NULL. Then, when we call `v3d_job_cleanup()`,
> job
> is NULL and the function returns.
>
> Fixes: 464c61e76de8 ("drm/v3d: Decouple job allocation from job
> initiation")
> Signed-off-by: Maíra Canal
> ---
> drivers/gpu/drm/v3d/v3d_submit.c | 35 +-
> --
> 1 file changed, 28 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_submit.c
> b/drivers/gpu/drm/v3d/v3d_submit.c
> index fcff41dd2315..88f63d526b22 100644
> --- a/drivers/gpu/drm/v3d/v3d_submit.c
> +++ b/drivers/gpu/drm/v3d/v3d_submit.c
> @@
Re: [PATCH v2 1/2] drm/dcss: request memory region
Hi Philipp,
kernel test robot noticed the following build errors:
[auto build test ERROR on v6.7]
[also build test ERROR on linus/master next-20240109]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Philipp-Stanner/drm-dcss-request-memory-region/20240109-182239
base: v6.7
patch link:
https://lore.kernel.org/r/20240109102032.16165-2-pstanner%40redhat.com
patch subject: [PATCH v2 1/2] drm/dcss: request memory region
config: arm64-allmodconfig
(https://download.01.org/0day-ci/archive/20240110/202401101201.yvs3iqfu-...@intel.com/config)
compiler: clang version 18.0.0git (https://github.com/llvm/llvm-project
7e186d366d6c7def0543acc255931f617e76dff0)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240110/202401101201.yvs3iqfu-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202401101201.yvs3iqfu-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/imx/dcss/dcss-dev.c:188:31: error: passing 'struct device'
>> to parameter of incompatible type 'struct device *'; take the address with &
188 | if (!devm_request_mem_region(pdev->dev, res->start, res_len,
"dcss")) {
| ^
| &
include/linux/ioport.h:306:24: note: expanded from macro
'devm_request_mem_region'
306 | __devm_request_region(dev, _resource, (start), (n),
(name))
| ^~~
include/linux/ioport.h:308:63: note: passing argument to parameter 'dev' here
308 | extern struct resource * __devm_request_region(struct device *dev,
| ^
1 error generated.
vim +188 drivers/gpu/drm/imx/dcss/dcss-dev.c
165
166 struct dcss_dev *dcss_dev_create(struct device *dev, bool hdmi_output)
167 {
168 struct platform_device *pdev = to_platform_device(dev);
169 int ret;
170 struct resource *res;
171 struct dcss_dev *dcss;
172 const struct dcss_type_data *devtype;
173 resource_size_t res_len;
174
175 devtype = of_device_get_match_data(dev);
176 if (!devtype) {
177 dev_err(dev, "no device match found\n");
178 return ERR_PTR(-ENODEV);
179 }
180
181 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
182 if (!res) {
183 dev_err(dev, "cannot get memory resource\n");
184 return ERR_PTR(-EINVAL);
185 }
186
187 res_len = res->end - res->start;
> 188 if (!devm_request_mem_region(pdev->dev, res->start, res_len,
> "dcss")) {
189 dev_err(dev, "cannot request memory region\n");
190 return ERR_PTR(-EBUSY);
191 }
192
193 dcss = kzalloc(sizeof(*dcss), GFP_KERNEL);
194 if (!dcss)
195 return ERR_PTR(-ENOMEM);
196
197 dcss->dev = dev;
198 dcss->devtype = devtype;
199 dcss->hdmi_output = hdmi_output;
200
201 ret = dcss_clks_init(dcss);
202 if (ret) {
203 dev_err(dev, "clocks initialization failed\n");
204 goto err;
205 }
206
207 dcss->of_port = of_graph_get_port_by_id(dev->of_node, 0);
208 if (!dcss->of_port) {
209 dev_err(dev, "no port@0 node in %pOF\n", dev->of_node);
210 ret = -ENODEV;
211 goto clks_err;
212 }
213
214 dcss->start_addr = res->start;
215
216 ret = dcss_submodules_init(dcss);
217 if (ret) {
218 of_node_put(dcss->of_port);
219 dev_err(dev, "submodules initialization failed\n");
220 goto clks_err;
221 }
222
223 init_completion(>disable_completion);
224
225 pm_runtime_set_autosuspend_delay(dev, 100);
226 pm_runtime_use_autosuspend(dev);
227 pm_runtime_set_suspended(dev);
228 pm_runtime_allow(dev);
229 pm_runtime_enable(dev);
230
231 return dcss;
232
233 clks_err:
234
回复: Re: 回复: Re: 回复: Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2
My plan is to obtain the process priority and convert it into the drm-scheduler's priority, so that the user is unaware and does not need to use environment variables to set it.
This is my patch:--- a/amdgpu/amdgpu_cs.c+++ b/amdgpu/amdgpu_cs.c@@ -31,6 +31,7 @@#if HAVE_ALLOCA_H# include #endif+#include #include "xf86drm.h"#include "amdgpu_drm.h"@@ -72,6 +73,14 @@ drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,}}+ int nice = getpriority(PRIO_PROCESS, 0);+ if (errno != EPERM)+ {+ if (nice > 0)+ priority = AMDGPU_CTX_PRIORITY_LOW;+ else if (nice < 0)+ priority = AMDGPU_CTX_PRIORITY_HIGH;+ }gpu_context = calloc(1, sizeof(struct amdgpu_context));if (!gpu_context)return -ENOMEM;
主 题：Re: 回复: Re: 回复: Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2 日 期：2024-01-09 17:36 发件人：maraeo 收件人：Christian König;
int p = -1.
unsigned u = p;
int p2 = u;
p2 is -1.
Marek
On Tue, Jan 9, 2024, 03:26 Christian König wrote:
Am 09.01.24 um 09:09 schrieb 李真能:
Thanks!
What about the second patch?
The second patch: amdgpu: change proirity value to be consistent with kernel.
As I want to pass AMDGPU_CTX_PRIORITY_LOW to kernel module drm-scheduler, if these two patches are not applyed,
It can not pass LOW priority to drm-scheduler.
Do you have any other suggestion?
Well what exactly is the problem? Just use AMD_PRIORITY=-512.As far as I can see that is how it is supposed to be used.Regards,Christian.
主 题：Re: 回复: Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2 日 期：2024-01-09 15:15 发件人：Christian König 收件人：李真能;Marek Olsak;Pierre-Eric Pelloux-Prayer;dri-devel;amd-gfx;
Am 09.01.24 um 02:50 schrieb 李真能:
When the priority value is passed to the kernel, the kernel compares it with the following values:
#define AMDGPU_CTX_PRIORITY_VERY_LOW -1023#define AMDGPU_CTX_PRIORITY_LOW -512#define AMDGPU_CTX_PRIORITY_NORMAL 0#define AMDGPU_CTX_PRIORITY_HIGH 512#define AMDGPU_CTX_PRIORITY_VERY_HIGH 1023
If priority is uint32_t, we can't set LOW and VERY_LOW value to kernel context priority,
Well that's nonsense.How the kernel handles the values and how userspace handles them are two separate things. You just need to make sure that it's always 32 bits.In other words if you have signed or unsigned data type in userspace is irrelevant for the kernel.
You can refer to the kernel function amdgpu_ctx_priority_permit, if priority is greater
than 0, and this process has not CAP_SYS_NICE capibility or DRM_MASTER permission,
this process will be exited.
Correct, that's intentional.Regards,Christian.
主 题：Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2 日 期：2024-01-09 00:28 发件人：Christian König 收件人：李真能;Marek Olsak;Pierre-Eric Pelloux-Prayer;dri-devel;amd-gfx;
Am 08.01.24 um 10:40 schrieb Zhenneng Li:> In order to pass the correct priority parameter to the kernel,> we must change priority type from uint32_t to int32_t.Hui what? Why should it matter if the parameter is signed or not?That doesn't seem to make sense.Regards,Christian.>> Signed-off-by: Zhenneng Li > ---> amdgpu/amdgpu.h | 2 +-> amdgpu/amdgpu_cs.c | 2 +-> 2 files changed, 2 insertions(+), 2 deletions(-)>> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h> index 9bdbf366..f46753f3 100644> --- a/amdgpu/amdgpu.h> +++ b/amdgpu/amdgpu.h> @@ -896,7 +896,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle handle,> *> */> int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,> - uint32_t priority,> + int32_t priority,> amdgpu_context_handle *context);> /**> * Create GPU execution Context> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c> index 49fc16c3..eb72c638 100644> --- a/amdgpu/amdgpu_cs.c> +++ b/amdgpu/amdgpu_cs.c> @@ -49,7 +49,7 @@ static int amdgpu_cs_reset_sem(amdgpu_semaphore_handle sem);> * \return 0 on success otherwise POSIX Error code> */> drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,> - uint32_t priority,> + int32_t priority,> amdgpu_context_handle *context)> {> struct amdgpu_context *gpu_context;
Re: [DO NOT MERGE v6 27/37] dt-bindings: ata: ata-generic: Add new targets
On 1/9/24 17:23, Yoshinori Sato wrote: > Added new ata-generic target. > - iodata,usl-5p-ata > - renesas,rts7751r2d-ata > > Each boards have simple IDE Interface. Use ATA generic driver. This looks OK to me, so feel free to add: Acked-by: Damien Le Moal Note: The "DO NOT MERGE" patch prefix almost got me to immediately delete this 37 patches in my inbox... If you wish to get this work merged after review, please use the regular "PATCH" prefix. No worries, the series will not be merged until is is reviewed :) -- Damien Le Moal Western Digital Research
[drm-misc:drm-misc-next 6/21] drivers/gpu/drm/rockchip/inno_hdmi.c:499:22: error: implicit declaration of function 'drm_atomic_get_new_connector_state'; did you mean 'drm_atomic_helper_connector_reset
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 632ca3c92f3840d91ba7ddda0271f84813036a11
commit: d3e040f450ec8e46ff42fa495a433b976ab47686 [6/21] drm/rockchip:
inno_hdmi: Get rid of mode_set
config: s390-randconfig-001-20240109
(https://download.01.org/0day-ci/archive/20240110/202401100949.zvrr0pia-...@intel.com/config)
compiler: s390-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240110/202401100949.zvrr0pia-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202401100949.zvrr0pia-...@intel.com/
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/rockchip/inno_hdmi.c: In function 'inno_hdmi_encoder_enable':
>> drivers/gpu/drm/rockchip/inno_hdmi.c:499:22: error: implicit declaration of
>> function 'drm_atomic_get_new_connector_state'; did you mean
>> 'drm_atomic_helper_connector_reset'? [-Werror=implicit-function-declaration]
499 | conn_state = drm_atomic_get_new_connector_state(state,
>connector);
| ^~
| drm_atomic_helper_connector_reset
>> drivers/gpu/drm/rockchip/inno_hdmi.c:499:20: warning: assignment to 'struct
>> drm_connector_state *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
499 | conn_state = drm_atomic_get_new_connector_state(state,
>connector);
|^
>> drivers/gpu/drm/rockchip/inno_hdmi.c:503:22: error: implicit declaration of
>> function 'drm_atomic_get_new_crtc_state'; did you mean
>> 'drm_atomic_helper_swap_state'? [-Werror=implicit-function-declaration]
503 | crtc_state = drm_atomic_get_new_crtc_state(state,
conn_state->crtc);
| ^
| drm_atomic_helper_swap_state
>> drivers/gpu/drm/rockchip/inno_hdmi.c:503:20: warning: assignment to 'struct
>> drm_crtc_state *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
503 | crtc_state = drm_atomic_get_new_crtc_state(state,
conn_state->crtc);
|^
cc1: some warnings being treated as errors
vim +499 drivers/gpu/drm/rockchip/inno_hdmi.c
491
492 static void inno_hdmi_encoder_enable(struct drm_encoder *encoder,
493 struct drm_atomic_state *state)
494 {
495 struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
496 struct drm_connector_state *conn_state;
497 struct drm_crtc_state *crtc_state;
498
> 499 conn_state = drm_atomic_get_new_connector_state(state,
> >connector);
500 if (WARN_ON(!conn_state))
501 return;
502
> 503 crtc_state = drm_atomic_get_new_crtc_state(state,
> conn_state->crtc);
504 if (WARN_ON(!crtc_state))
505 return;
506
507 inno_hdmi_setup(hdmi, _state->adjusted_mode);
508 inno_hdmi_set_pwr_mode(hdmi, NORMAL);
509 }
510
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
[PATCH] nouveau/gsp: handle engines in runl without nonstall interrupts.
From: Dave Airlie
It appears on TU106 GPUs (2070), that some of the nvdec engines
are in the runlist but have no valid nonstall interrupt, nouveau
didn't handle that too well.
This should let nouveau/gsp work on those.
Cc: sta...@vger.kernel.org # v6.7+
---
drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c | 4
drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c | 8 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c
index c8ce7ff18713..e74493a4569e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/ga100.c
@@ -550,6 +550,10 @@ ga100_fifo_nonstall_ctor(struct nvkm_fifo *fifo)
struct nvkm_engn *engn = list_first_entry(>engns,
typeof(*engn), head);
runl->nonstall.vector = engn->func->nonstall(engn);
+
+ /* if no nonstall vector just keep going */
+ if (runl->nonstall.vector == -1)
+ continue;
if (runl->nonstall.vector < 0) {
RUNL_ERROR(runl, "nonstall %d", runl->nonstall.vector);
return runl->nonstall.vector;
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
index b903785056b5..3454c7d29502 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
@@ -351,7 +351,7 @@ r535_engn_nonstall(struct nvkm_engn *engn)
int ret;
ret = nvkm_gsp_intr_nonstall(subdev->device->gsp, subdev->type,
subdev->inst);
- WARN_ON(ret < 0);
+ WARN_ON(ret == -ENOENT);
return ret;
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
index 04bceaa28a19..da1bebb896f7 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/base.c
@@ -25,12 +25,8 @@ int
nvkm_gsp_intr_nonstall(struct nvkm_gsp *gsp, enum nvkm_subdev_type type, int
inst)
{
for (int i = 0; i < gsp->intr_nr; i++) {
- if (gsp->intr[i].type == type && gsp->intr[i].inst == inst) {
- if (gsp->intr[i].nonstall != ~0)
- return gsp->intr[i].nonstall;
-
- return -EINVAL;
- }
+ if (gsp->intr[i].type == type && gsp->intr[i].inst == inst)
+ return gsp->intr[i].nonstall;
}
return -ENOENT;
--
2.43.0
[PATCH v12 7/7] phy: freescale: Add HDMI PHY driver for i.MX8MQ
Add Cadence HDP-TX HDMI PHY driver for i.MX8MQ. Cadence HDP-TX PHY could be put in either DP mode or HDMI mode base on the configuration chosen. HDMI PHY mode is configurated in the driver. Signed-off-by: Sandor Yu Tested-by: Alexander Stein --- v11->v12: - Adjust clk disable order. - Return error code to replace -1 for function wait_for_ack(). - Use bool for variable pclk_in. - Add year 2024 to copyright. drivers/phy/freescale/Kconfig | 10 + drivers/phy/freescale/Makefile | 1 + drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c | 959 3 files changed, 970 insertions(+) create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig index c39709fd700ac..14f47b7cc77ab 100644 --- a/drivers/phy/freescale/Kconfig +++ b/drivers/phy/freescale/Kconfig @@ -45,6 +45,16 @@ config PHY_FSL_IMX8MQ_DP Enable this to support the Cadence HDPTX DP PHY driver on i.MX8MQ SOC. +config PHY_FSL_IMX8MQ_HDMI + tristate "Freescale i.MX8MQ HDMI PHY support" + depends on OF && HAS_IOMEM + depends on COMMON_CLK + select GENERIC_PHY + select CDNS_MHDP_HELPER + help + Enable this to support the Cadence HDPTX HDMI PHY driver + on i.MX8MQ SOC. + endif config PHY_FSL_LYNX_28G diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile index 47e5285209fa8..1380ac31c2ead 100644 --- a/drivers/phy/freescale/Makefile +++ b/drivers/phy/freescale/Makefile @@ -1,5 +1,6 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)+= phy-fsl-imx8mq-dp.o +obj-$(CONFIG_PHY_FSL_IMX8MQ_HDMI) += phy-fsl-imx8mq-hdmi.o obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c new file mode 100644 index 0..9e03c726f290c --- /dev/null +++ b/drivers/phy/freescale/phy-fsl-imx8mq-hdmi.c @@ -0,0 +1,959 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Cadence High-Definition Multimedia Interface (HDMI) PHY driver + * + * Copyright (C) 2022-2024 NXP Semiconductor, Inc. + */ +#include +#include +#include +#include +#include +#include +#include + +#define ADDR_PHY_AFE 0x8 + +/* PHY registers */ +#define CMN_SSM_BIAS_TMR 0x0022 +#define CMN_PLLSM0_USER_DEF_CTRL 0x002f +#define CMN_PSM_CLK_CTRL 0x0061 +#define CMN_CDIAG_REFCLK_CTRL 0x0062 +#define CMN_PLL0_VCOCAL_START 0x0081 +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084 +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085 +#define CMN_TXPUCAL_CTRL 0x00e0 +#define CMN_TXPDCAL_CTRL 0x00f0 +#define CMN_TXPU_ADJ_CTRL 0x0108 +#define CMN_TXPD_ADJ_CTRL 0x010c +#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0 +#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1 +#define CMN_DIAG_PLL0_OVRD 0x01c2 +#define CMN_DIAG_PLL0_TEST_MODE0x01c4 +#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5 +#define CMN_DIAG_PLL0_CP_TUNE 0x01c6 +#define CMN_DIAG_PLL0_LF_PROG 0x01c7 +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8 +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9 +#define CMN_DIAG_PLL0_INCLK_CTRL 0x01ca +#define CMN_DIAG_PLL0_PXL_DIVH 0x01cb +#define CMN_DIAG_PLL0_PXL_DIVL 0x01cc +#define CMN_DIAG_HSCLK_SEL 0x01e0 +#define XCVR_PSM_RCTRL 0x4001 +#define TX_TXCC_CAL_SCLR_MULT_00x4047 +#define TX_TXCC_CPOST_MULT_00_00x404c +#define XCVR_DIAG_PLLDRC_CTRL 0x40e0 +#define XCVR_DIAG_PLLDRC_CTRL 0x40e0 +#define XCVR_DIAG_HSCLK_SEL0x40e1 +#define XCVR_DIAG_BIDI_CTRL0x40e8 +#define TX_PSC_A0 0x4100 +#define TX_PSC_A1 0x4101 +#define TX_PSC_A2 0x4102 +#define TX_PSC_A3 0x4103 +#define TX_DIAG_TX_CTRL0x41e0 +#define TX_DIAG_TX_DRV 0x41e1 +#define TX_DIAG_BGREF_PREDRV_DELAY 0x41e7 +#define TX_DIAG_ACYA_0 0x41ff +#define TX_DIAG_ACYA_1 0x43ff +#define TX_DIAG_ACYA_2 0x45ff +#define TX_DIAG_ACYA_3 0x47ff +#define TX_ANA_CTRL_REG_1 0x5020 +#define TX_ANA_CTRL_REG_2 0x5021 +#define TX_DIG_CTRL_REG_2
[PATCH v12 6/7] phy: freescale: Add DisplayPort PHY driver for i.MX8MQ
Add Cadence HDP-TX DisplayPort PHY driver for i.MX8MQ Cadence HDP-TX PHY could be put in either DP mode or HDMI mode base on the configuration chosen. DisplayPort PHY mode is configurated in the driver. Signed-off-by: Sandor Yu --- v11->v12: - Return error code to replace -1 for function wait_for_ack(). - Set cdns_phy->power_up = false in phy_power_down function. - Remove "RATE_8_1 = 81", it is not used in driver. - Add year 2024 to copyright. drivers/phy/freescale/Kconfig | 10 + drivers/phy/freescale/Makefile| 1 + drivers/phy/freescale/phy-fsl-imx8mq-dp.c | 726 ++ 3 files changed, 737 insertions(+) create mode 100644 drivers/phy/freescale/phy-fsl-imx8mq-dp.c diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig index 853958fb2c063..c39709fd700ac 100644 --- a/drivers/phy/freescale/Kconfig +++ b/drivers/phy/freescale/Kconfig @@ -35,6 +35,16 @@ config PHY_FSL_IMX8M_PCIE Enable this to add support for the PCIE PHY as found on i.MX8M family of SOCs. +config PHY_FSL_IMX8MQ_DP + tristate "Freescale i.MX8MQ DP PHY support" + depends on OF && HAS_IOMEM + depends on COMMON_CLK + select GENERIC_PHY + select CDNS_MHDP_HELPER + help + Enable this to support the Cadence HDPTX DP PHY driver + on i.MX8MQ SOC. + endif config PHY_FSL_LYNX_28G diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile index cedb328bc4d28..47e5285209fa8 100644 --- a/drivers/phy/freescale/Makefile +++ b/drivers/phy/freescale/Makefile @@ -1,4 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only +obj-$(CONFIG_PHY_FSL_IMX8MQ_DP)+= phy-fsl-imx8mq-dp.o obj-$(CONFIG_PHY_FSL_IMX8MQ_USB) += phy-fsl-imx8mq-usb.o obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY) += phy-fsl-imx8-mipi-dphy.o diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-dp.c b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c new file mode 100644 index 0..2e24ca04c5980 --- /dev/null +++ b/drivers/phy/freescale/phy-fsl-imx8mq-dp.c @@ -0,0 +1,726 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Cadence HDP-TX Display Port Interface (DP) PHY driver + * + * Copyright (C) 2022-2024 NXP Semiconductor, Inc. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#define ADDR_PHY_AFE 0x8 + +/* PHY registers */ +#define CMN_SSM_BIAS_TMR 0x0022 +#define CMN_PLLSM0_PLLEN_TMR 0x0029 +#define CMN_PLLSM0_PLLPRE_TMR 0x002a +#define CMN_PLLSM0_PLLVREF_TMR 0x002b +#define CMN_PLLSM0_PLLLOCK_TMR 0x002c +#define CMN_PLLSM0_USER_DEF_CTRL 0x002f +#define CMN_PSM_CLK_CTRL 0x0061 +#define CMN_PLL0_VCOCAL_START 0x0081 +#define CMN_PLL0_VCOCAL_INIT_TMR 0x0084 +#define CMN_PLL0_VCOCAL_ITER_TMR 0x0085 +#define CMN_PLL0_INTDIV0x0094 +#define CMN_PLL0_FRACDIV 0x0095 +#define CMN_PLL0_HIGH_THR 0x0096 +#define CMN_PLL0_DSM_DIAG 0x0097 +#define CMN_PLL0_SS_CTRL2 0x0099 +#define CMN_ICAL_INIT_TMR 0x00c4 +#define CMN_ICAL_ITER_TMR 0x00c5 +#define CMN_RXCAL_INIT_TMR 0x00d4 +#define CMN_RXCAL_ITER_TMR 0x00d5 +#define CMN_TXPUCAL_INIT_TMR 0x00e4 +#define CMN_TXPUCAL_ITER_TMR 0x00e5 +#define CMN_TXPDCAL_INIT_TMR 0x00f4 +#define CMN_TXPDCAL_ITER_TMR 0x00f5 +#define CMN_ICAL_ADJ_INIT_TMR 0x0102 +#define CMN_ICAL_ADJ_ITER_TMR 0x0103 +#define CMN_RX_ADJ_INIT_TMR0x0106 +#define CMN_RX_ADJ_ITER_TMR0x0107 +#define CMN_TXPU_ADJ_INIT_TMR 0x010a +#define CMN_TXPU_ADJ_ITER_TMR 0x010b +#define CMN_TXPD_ADJ_INIT_TMR 0x010e +#define CMN_TXPD_ADJ_ITER_TMR 0x010f +#define CMN_DIAG_PLL0_FBH_OVRD 0x01c0 +#define CMN_DIAG_PLL0_FBL_OVRD 0x01c1 +#define CMN_DIAG_PLL0_OVRD 0x01c2 +#define CMN_DIAG_PLL0_TEST_MODE0x01c4 +#define CMN_DIAG_PLL0_V2I_TUNE 0x01c5 +#define CMN_DIAG_PLL0_CP_TUNE 0x01c6 +#define CMN_DIAG_PLL0_LF_PROG 0x01c7 +#define CMN_DIAG_PLL0_PTATIS_TUNE1 0x01c8 +#define CMN_DIAG_PLL0_PTATIS_TUNE2 0x01c9 +#define CMN_DIAG_HSCLK_SEL 0x01e0 +#define CMN_DIAG_PER_CAL_ADJ 0x01ec +#define CMN_DIAG_CAL_CTRL 0x01ed +#define CMN_DIAG_ACYA 0x01ff +#define XCVR_PSM_RCTRL 0x4001 +#define XCVR_PSM_CAL_TMR
[PATCH v12 4/7] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
Add a new DRM DisplayPort and HDMI bridge driver for Candence MHDP8501
used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
standards according embedded Firmware running in the uCPU.
For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
SOC's ROM code. Bootload binary included respective specific firmware
is required.
Driver will check display connector type and
then load the corresponding driver.
Signed-off-by: Sandor Yu
Tested-by: Alexander Stein
---
v11->v12:
- Replace DRM_INFO with dev_info or dev_warn.
- Replace DRM_ERROR with dev_err.
- Return ret when cdns_mhdp_dpcd_read failed in function
cdns_dp_aux_transferi().
- Remove unused parmeter in function cdns_dp_get_msa_misc
and use two separate variables for color space and bpc.
- Add year 2024 to copyright.
drivers/gpu/drm/bridge/cadence/Kconfig| 16 +
drivers/gpu/drm/bridge/cadence/Makefile | 2 +
.../drm/bridge/cadence/cdns-mhdp8501-core.c | 315
.../drm/bridge/cadence/cdns-mhdp8501-core.h | 365 +
.../gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c | 699 ++
.../drm/bridge/cadence/cdns-mhdp8501-hdmi.c | 678 +
6 files changed, 2075 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.h
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index e0973339e9e33..45848e741f5f4 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -51,3 +51,19 @@ config DRM_CDNS_MHDP8546_J721E
initializes the J721E Display Port and sets up the
clock and data muxes.
endif
+
+config DRM_CDNS_MHDP8501
+ tristate "Cadence MHDP8501 DP/HDMI bridge"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ select DRM_DISPLAY_DP_HELPER
+ select DRM_DISPLAY_HELPER
+ select CDNS_MHDP_HELPER
+ select DRM_CDNS_AUDIO
+ depends on OF
+ help
+ Support Cadence MHDP8501 DisplayPort/HDMI bridge.
+ Cadence MHDP8501 support one or more protocols,
+ including DisplayPort and HDMI.
+ To use the DP and HDMI drivers, their respective
+ specific firmware is required.
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index 087dc074820d7..02c1a9f3cf6fc 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -6,3 +6,5 @@ obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
+obj-$(CONFIG_DRM_CDNS_MHDP8501) += cdns-mhdp8501.o
+cdns-mhdp8501-y := cdns-mhdp8501-core.o cdns-mhdp8501-dp.o cdns-mhdp8501-hdmi.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
new file mode 100644
index 0..3080c7507a012
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
@@ -0,0 +1,315 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence Display Port Interface (DP) driver
+ *
+ * Copyright (C) 2023, 2024 NXP Semiconductor, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cdns-mhdp8501-core.h"
+
+static int cdns_mhdp8501_read_hpd(struct cdns_mhdp8501_device *mhdp)
+{
+ u8 status;
+ int ret;
+
+ mutex_lock(>mbox_mutex);
+
+ ret = cdns_mhdp_mailbox_send(>base, MB_MODULE_ID_GENERAL,
+GENERAL_GET_HPD_STATE, 0, NULL);
+ if (ret)
+ goto err_get_hpd;
+
+ ret = cdns_mhdp_mailbox_recv_header(>base, MB_MODULE_ID_GENERAL,
+ GENERAL_GET_HPD_STATE,
+ sizeof(status));
+ if (ret)
+ goto err_get_hpd;
+
+ ret = cdns_mhdp_mailbox_recv_data(>base, , sizeof(status));
+ if (ret)
+ goto err_get_hpd;
+
+ mutex_unlock(>mbox_mutex);
+
+ return status;
+
+err_get_hpd:
+ dev_err(mhdp->dev, "read hpd failed: %d\n", ret);
+ mutex_unlock(>mbox_mutex);
+
+ return ret;
+}
+
+enum drm_connector_status cdns_mhdp8501_detect(struct cdns_mhdp8501_device
*mhdp)
+{
+ u8 hpd = 0xf;
+
+ hpd = cdns_mhdp8501_read_hpd(mhdp);
+ if (hpd == 1)
+ return connector_status_connected;
+ else if (hpd == 0)
+ return connector_status_disconnected;
+
+ dev_warn(mhdp->dev, "Unknown cable status, hdp=%u\n", hpd);
+ return connector_status_unknown;
+}
+
+static void hotplug_work_func(struct work_struct
[PATCH v12 5/7] dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY
Add bindings for Freescale iMX8MQ DP and HDMI PHY.
Signed-off-by: Sandor Yu
Reviewed-by: Rob Herring
---
v9->v12:
*No change.
.../bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
new file mode 100644
index 0..917f113503dca
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-dp-hdmi-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/fsl,imx8mq-dp-hdmi-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence HDP-TX DP/HDMI PHY for Freescale i.MX8MQ SoC
+
+maintainers:
+ - Sandor Yu
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8mq-dp-phy
+ - fsl,imx8mq-hdmi-phy
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: PHY reference clock.
+ - description: APB clock.
+
+ clock-names:
+items:
+ - const: ref
+ - const: apb
+
+ "#phy-cells":
+const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - "#phy-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+dp_phy: phy@32c0 {
+compatible = "fsl,imx8mq-dp-phy";
+reg = <0x32c0 0x10>;
+#phy-cells = <0>;
+clocks = <_phy_27m>, < IMX8MQ_CLK_DISP_APB_ROOT>;
+clock-names = "ref", "apb";
+};
--
2.34.1
[PATCH v12 3/7] dt-bindings: display: bridge: Add Cadence MHDP8501
Add bindings for Cadence MHDP8501 DisplayPort/HDMI bridge.
Signed-off-by: Sandor Yu
Reviewed-by: Krzysztof Kozlowski
---
v9->v12:
*No change.
.../display/bridge/cdns,mhdp8501.yaml | 104 ++
1 file changed, 104 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
new file mode 100644
index 0..3ae643845cfee
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8501.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8501.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MHDP8501 DP/HDMI bridge
+
+maintainers:
+ - Sandor Yu
+
+description:
+ Cadence MHDP8501 DisplayPort/HDMI interface.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx8mq-mhdp8501
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+description: MHDP8501 DP/HDMI APB clock.
+
+ phys:
+maxItems: 1
+description:
+ phandle to the DisplayPort or HDMI PHY
+
+ interrupts:
+items:
+ - description: Hotplug cable plugin.
+ - description: Hotplug cable plugout.
+
+ interrupt-names:
+items:
+ - const: plug_in
+ - const: plug_out
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Input port from display controller output.
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Output port to DisplayPort or HDMI connector.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - interrupt-names
+ - phys
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+mhdp: display-bridge@32c0 {
+compatible = "fsl,imx8mq-mhdp8501";
+reg = <0x32c0 0x10>;
+interrupts = ,
+ ;
+interrupt-names = "plug_in", "plug_out";
+clocks = < IMX8MQ_CLK_DISP_APB_ROOT>;
+phys = <_phy>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+
+mhdp_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+
+mhdp_out: endpoint {
+remote-endpoint = <_connector>;
+};
+};
+};
+};
--
2.34.1
[PATCH v12 2/7] phy: Add HDMI configuration options
Allow HDMI PHYs to be configured through the generic
functions through a custom structure added to the generic union.
The parameters added here are based on HDMI PHY
implementation practices. The current set of parameters
should cover the potential users.
Signed-off-by: Sandor Yu
Reviewed-by: Dmitry Baryshkov
Acked-by: Vinod Koul
---
v9->v12:
*No change.
include/linux/phy/phy-hdmi.h | 24
include/linux/phy/phy.h | 7 ++-
2 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 include/linux/phy/phy-hdmi.h
diff --git a/include/linux/phy/phy-hdmi.h b/include/linux/phy/phy-hdmi.h
new file mode 100644
index 0..b7de88e9090f0
--- /dev/null
+++ b/include/linux/phy/phy-hdmi.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright 2022 NXP
+ */
+
+#ifndef __PHY_HDMI_H_
+#define __PHY_HDMI_H_
+
+#include
+/**
+ * struct phy_configure_opts_hdmi - HDMI configuration set
+ * @pixel_clk_rate: Pixel clock of video modes in KHz.
+ * @bpc: Maximum bits per color channel.
+ * @color_space: Colorspace in enum hdmi_colorspace.
+ *
+ * This structure is used to represent the configuration state of a HDMI phy.
+ */
+struct phy_configure_opts_hdmi {
+ unsigned int pixel_clk_rate;
+ unsigned int bpc;
+ enum hdmi_colorspace color_space;
+};
+
+#endif /* __PHY_HDMI_H_ */
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index f6d607ef0e801..94d489a8a163c 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
@@ -42,7 +43,8 @@ enum phy_mode {
PHY_MODE_MIPI_DPHY,
PHY_MODE_SATA,
PHY_MODE_LVDS,
- PHY_MODE_DP
+ PHY_MODE_DP,
+ PHY_MODE_HDMI,
};
enum phy_media {
@@ -60,11 +62,14 @@ enum phy_media {
* the DisplayPort protocol.
* @lvds: Configuration set applicable for phys supporting
* the LVDS phy mode.
+ * @hdmi: Configuration set applicable for phys supporting
+ * the HDMI phy mode.
*/
union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
struct phy_configure_opts_dpdp;
struct phy_configure_opts_lvds lvds;
+ struct phy_configure_opts_hdmi hdmi;
};
/**
--
2.34.1
[PATCH v12 1/7] drm: bridge: Cadence: Create mhdp helper driver
MHDP8546 mailbox access functions will be share to other mhdp driver
and Cadence HDP-TX HDMI/DP PHY drivers.
Create a new mhdp helper driver and move all those functions into.
cdns_mhdp_reg_write() is renamed to cdns_mhdp_dp_reg_write(),
because it use the DPTX command ID DPTX_WRITE_REGISTER.
New cdns_mhdp_reg_write() is created with the general command ID
GENERAL_REGISTER_WRITE.
rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver,
use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write()
same as the other mailbox access functions.
Signed-off-by: Sandor Yu
---
v11->v12:
- Move status initialize out of mbox_mutex.
- Reorder API functions in alphabetical.
- Add notes for malibox access functions.
- Add year 2024 to copyright.
drivers/gpu/drm/bridge/cadence/Kconfig| 4 +
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
.../gpu/drm/bridge/cadence/cdns-mhdp-helper.c | 304 +
.../drm/bridge/cadence/cdns-mhdp8546-core.c | 403 +++---
.../drm/bridge/cadence/cdns-mhdp8546-core.h | 44 +-
include/drm/bridge/cdns-mhdp-helper.h | 97 +
6 files changed, 479 insertions(+), 374 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
create mode 100644 include/drm/bridge/cdns-mhdp-helper.h
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index cced81633ddcd..e0973339e9e33 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -21,6 +21,9 @@ config DRM_CDNS_DSI_J721E
the routing of the DSS DPI signal to the Cadence DSI.
endif
+config CDNS_MHDP_HELPER
+ tristate
+
config DRM_CDNS_MHDP8546
tristate "Cadence DPI/DP bridge"
select DRM_DISPLAY_DP_HELPER
@@ -28,6 +31,7 @@ config DRM_CDNS_MHDP8546
select DRM_DISPLAY_HELPER
select DRM_KMS_HELPER
select DRM_PANEL_BRIDGE
+ select CDNS_MHDP_HELPER
depends on OF
help
Support Cadence DPI to DP bridge. This is an internal
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index c95fd5b81d137..087dc074820d7 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
cdns-dsi-y := cdns-dsi-core.o
cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
+obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
new file mode 100644
index 0..ba31695b483ac
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
@@ -0,0 +1,304 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2023, 2024 NXP Semiconductor, Inc.
+ *
+ */
+#include
+#include
+#include
+
+/* Mailbox helper functions */
+static int cdns_mhdp_mailbox_read(struct cdns_mhdp_base *base)
+{
+ int ret, empty;
+
+ WARN_ON(!mutex_is_locked(base->mbox_mutex));
+
+ ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_EMPTY,
+empty, !empty, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ return readl(base->regs + CDNS_MAILBOX_RX_DATA) & 0xff;
+}
+
+static int cdns_mhdp_mailbox_write(struct cdns_mhdp_base *base, u8 val)
+{
+ int ret, full;
+
+ WARN_ON(!mutex_is_locked(base->mbox_mutex));
+
+ ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_FULL,
+full, !full, MAILBOX_RETRY_US,
+MAILBOX_TIMEOUT_US);
+ if (ret < 0)
+ return ret;
+
+ writel(val, base->regs + CDNS_MAILBOX_TX_DATA);
+
+ return 0;
+}
+
+int cdns_mhdp_mailbox_recv_header(struct cdns_mhdp_base *base,
+ u8 module_id, u8 opcode,
+ u16 req_size)
+{
+ u32 mbox_size, i;
+ u8 header[4];
+ int ret;
+
+ /* read the header of the message */
+ for (i = 0; i < sizeof(header); i++) {
+ ret = cdns_mhdp_mailbox_read(base);
+ if (ret < 0)
+ return ret;
+
+ header[i] = ret;
+ }
+
+ mbox_size = get_unaligned_be16(header + 2);
+
+ if (opcode != header[0] || module_id != header[1] ||
+ req_size != mbox_size) {
+ /*
+* If the message in mailbox is not what we want, we need to
+* clear the mailbox by reading its contents.
+*/
+ for (i = 0; i < mbox_size; i++)
+ if (cdns_mhdp_mailbox_read(base) < 0)
[PATCH v12 0/7] Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ
The patch set initial support Cadence MHDP8501(HDMI/DP) DRM bridge driver and Cadence HDP-TX PHY(HDMI/DP) drivers for Freescale i.MX8MQ. The patch set compose of DRM bridge drivers and PHY drivers. Both of them need patch #1 and #2 to pass build. DRM bridges driver patches: #1: drm: bridge: Cadence: Creat mhdp helper driver #2: phy: Add HDMI configuration options #3: dt-bindings: display: bridge: Add Cadence MHDP8501 #4: drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver PHY driver patches: #1: drm: bridge: Cadence: Creat mhdp helper driver #2: phy: Add HDMI configuration options #5: dt-bindings: phy: Add Freescale iMX8MQ DP and HDMI PHY #6: phy: freescale: Add DisplayPort PHY driver for i.MX8MQ #7: phy: freescale: Add HDMI PHY driver for i.MX8MQ v11->v12: Patch #1: - Move status initialize out of mbox_mutex. - Reorder API functions in alphabetical. - Add notes for malibox access functions. - Add year 2024 to copyright. Patch #4: - Replace DRM_INFO with dev_info or dev_warn. - Replace DRM_ERROR with dev_err. - Return ret when cdns_mhdp_dpcd_read failed in function cdns_dp_aux_transferi(). - Remove unused parmeter in function cdns_dp_get_msa_misc and use two separate variables for color space and bpc. - Add year 2024 to copyright. Patch #6: - Return error code to replace -1 for function wait_for_ack(). - Set cdns_phy->power_up = false in phy_power_down function. - Remove "RATE_8_1 = 81", it is not used in driver. - Add year 2024 to copyright. Patch #7: - Adjust clk disable order. - Return error code to replace -1 for function wait_for_ack(). - Use bool for variable pclk_in. - Add year 2024 to copyright. v10->v11: - rewrite cdns_mhdp_set_firmware_active() in mhdp8546 core driver, use cdns_mhdp_mailbox_send() to replace cdns_mhdp_mailbox_write() same as the other mailbox access functions. - use static for cdns_mhdp_mailbox_write() and cdns_mhdp_mailbox_read() and remove them from EXPORT_SYMBOL_GPL(). - remove MODULE_ALIAS() from mhdp8501 driver. v9->v10: - Create mhdp helper driver to replace macro functions, move all mhdp mailbox access functions and common functions into the helper driver. Patch #1:drm: bridge: Cadence: Creat mhdp helper driver it is totaly different with v9. v8->v9: - Remove compatible string "cdns,mhdp8501" that had removed from dt-bindings file in v8. - Add Dmitry's R-b tag to patch #2 - Add Krzysztof's R-b tag to patch #3 v7->v8: MHDP8501 HDMI/DP: - Correct DT node name to "display-bridge". - Remove "cdns,mhdp8501" from mhdp8501 dt-binding doc. HDMI/DP PHY: - Introduced functions `wait_for_ack` and `wait_for_ack_clear` to handle waiting with acknowledgment bits set and cleared respectively. - Use FIELD_PRE() to set bitfields for both HDMI and DP PHY. v6->v7: MHDP8501 HDMI/DP: - Combine HDMI and DP driver into one mhdp8501 driver. Use the connector type to load the corresponding functions. - Remove connector init functions. - Add in phy_hdmi.h to reuse ‘enum hdmi_colorspace’. HDMI/DP PHY: - Lowercase hex values - Fix parameters indent issue on some functions - Replace ‘udelay’ with ‘usleep_range’ v5->v6: HDMI/DP bridge driver - 8501 is the part number of Cadence MHDP on i.MX8MQ. Use MHDP8501 to name hdmi/dp drivers and files. - Add compatible "fsl,imx8mq-mhdp8501-dp" for i.MX8MQ DP driver - Add compatible "fsl,imx8mq-mhdp8501-hdmi" for i.MX8MQ HDMI driver - Combine HDMI and DP dt-bindings into one file cdns,mhdp8501.yaml - Fix HDMI scrambling is not enable issue when driver working in 4Kp60 mode. - Add HDMI/DP PHY API mailbox protect. HDMI/DP PHY driver: - Rename DP and HDMI PHY files and move to folder phy/freescale/ - Remove properties num_lanes and link_rate from DP PHY driver. - Combine HDMI and DP dt-bindings into one file fsl,imx8mq-dp-hdmi-phy.yaml - Update compatible string to "fsl,imx8mq-dp-phy". - Update compatible string to "fsl,imx8mq-hdmi-phy". v4->v5: - Drop "clk" suffix in clock name. - Add output port property in the example of hdmi/dp. v3->v4: dt-bindings: - Correct dt-bindings coding style and address review comments. - Add apb_clk description. - Add output port for HDMI/DP connector PHY: - Alphabetically sorted in Kconfig and Makefile for DP and HDMI PHY - Remove unused registers define from HDMI and DP PHY drivers. - More description in phy_hdmi.h. - Add apb_clk to HDMI and DP phy driver. HDMI/DP: - Use get_unaligned_le32() to replace hardcode type conversion in HDMI AVI infoframe data fill function. - Add mailbox mutex lock in HDMI/DP driver for phy functions to reslove race conditions between HDMI/DP and PHY drivers. - Add apb_clk to both HDMI and DP driver. - Rename some function names and add prefix with "cdns_hdmi/cdns_dp". - Remove bpc 12 and 16 optional that not supported. v2->v3: Address comments for dt-bindings files. - Correct dts-bindings file names Rename phy-cadence-hdptx-dp.yaml to cdns,mhdp-imx8mq-dp.yaml Rename phy-cadence-hdptx-hdmi.yaml to cdns,mhdp-imx8mq-hdmi.yaml - Drop redundant
Re: [PATCH v2 1/2] drm/dcss: request memory region
Hi Philipp,
kernel test robot noticed the following build errors:
[auto build test ERROR on v6.7]
[also build test ERROR on linus/master next-20240109]
[cannot apply to drm-misc/drm-misc-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Philipp-Stanner/drm-dcss-request-memory-region/20240109-182239
base: v6.7
patch link:
https://lore.kernel.org/r/20240109102032.16165-2-pstanner%40redhat.com
patch subject: [PATCH v2 1/2] drm/dcss: request memory region
config: arm64-defconfig
(https://download.01.org/0day-ci/archive/20240110/202401100801.1wiy3zed-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20240110/202401100801.1wiy3zed-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202401100801.1wiy3zed-...@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/device.h:17,
from include/linux/platform_device.h:13,
from drivers/gpu/drm/imx/dcss/dcss-dev.c:9:
drivers/gpu/drm/imx/dcss/dcss-dev.c: In function 'dcss_dev_create':
>> drivers/gpu/drm/imx/dcss/dcss-dev.c:188:42: error: incompatible type for
>> argument 1 of '__devm_request_region'
188 | if (!devm_request_mem_region(pdev->dev, res->start, res_len,
"dcss")) {
| ^
| |
| struct device
include/linux/ioport.h:306:31: note: in definition of macro
'devm_request_mem_region'
306 | __devm_request_region(dev, _resource, (start), (n),
(name))
| ^~~
include/linux/ioport.h:308:63: note: expected 'struct device *' but argument
is of type 'struct device'
308 | extern struct resource * __devm_request_region(struct device *dev,
|~~~^~~
vim +/__devm_request_region +188 drivers/gpu/drm/imx/dcss/dcss-dev.c
165
166 struct dcss_dev *dcss_dev_create(struct device *dev, bool hdmi_output)
167 {
168 struct platform_device *pdev = to_platform_device(dev);
169 int ret;
170 struct resource *res;
171 struct dcss_dev *dcss;
172 const struct dcss_type_data *devtype;
173 resource_size_t res_len;
174
175 devtype = of_device_get_match_data(dev);
176 if (!devtype) {
177 dev_err(dev, "no device match found\n");
178 return ERR_PTR(-ENODEV);
179 }
180
181 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
182 if (!res) {
183 dev_err(dev, "cannot get memory resource\n");
184 return ERR_PTR(-EINVAL);
185 }
186
187 res_len = res->end - res->start;
> 188 if (!devm_request_mem_region(pdev->dev, res->start, res_len,
> "dcss")) {
189 dev_err(dev, "cannot request memory region\n");
190 return ERR_PTR(-EBUSY);
191 }
192
193 dcss = kzalloc(sizeof(*dcss), GFP_KERNEL);
194 if (!dcss)
195 return ERR_PTR(-ENOMEM);
196
197 dcss->dev = dev;
198 dcss->devtype = devtype;
199 dcss->hdmi_output = hdmi_output;
200
201 ret = dcss_clks_init(dcss);
202 if (ret) {
203 dev_err(dev, "clocks initialization failed\n");
204 goto err;
205 }
206
207 dcss->of_port = of_graph_get_port_by_id(dev->of_node, 0);
208 if (!dcss->of_port) {
209 dev_err(dev, "no port@0 node in %pOF\n", dev->of_node);
210 ret = -ENODEV;
211 goto clks_err;
212 }
213
214 dcss->start_addr = res->start;
215
216 ret = dcss_submodules_init(dcss);
217 if (ret) {
218 of_node_put(dcss->of_port);
219 dev_err(dev, "submodules initialization failed\n");
220 goto clks_err;
221 }
222
223 init_completion(>disable_completion);
224
225 pm_runtime_set_autosuspend_delay(dev, 100);
226 p
Re: BUG / design challenge: vmwgfx + PRIME handle free == clobbering errno
On Tue, Jan 9, 2024 at 11:06 AM Xaver Hugl wrote: > > Hi, > > KWin does use DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT. Can you point me to the code that implements it? Just wanted to take a quick look, because I didn't see the cursor on KDE 6 after fixing the kernel oops. > Tying the check to > DRM_CLIENT_CAP_ATOMIC instead would IMO make more sense though (even if it's > still weird) and would work with older versions of KWin and other compositors. Unfortunately xf86-video-modesetting advertises CLIENT_CAP_ATOMIC and uses GL where our GL driver assumes the prime object is not GEM. Not impossible, as mentioned before, we can always add code to the kernel that handles both but I don't think there's any particularly clean solutions here. We'll probably play with a few solutions and see which one is the cleanest. z
[PATCH] drm/imagination: fix ARRAY_SIZE build error
Fix a build error when using GCC 13.2.0 from kernel.org crosstools
by changing ARRAY_SIZE() to the macro PVR_MIPS_PT_PAGE_COUNT:
drivers/gpu/drm/imagination/pvr_vm_mips.c: In function 'pvr_vm_mips_fini':
../include/linux/array_size.h:11:25: warning: overflow in conversion from 'long
unsigned int' to 'int' changes value from '18446744073709551615' to '-1'
[-Woverflow]
11 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
| ^
drivers/gpu/drm/imagination/pvr_vm_mips.c:105:24: note: in expansion of macro
'ARRAY_SIZE'
105 | for (page_nr = ARRAY_SIZE(mips_data->pt_pages) - 1; page_nr >=
0; page_nr--) {
|^~
Fixes: 927f3e0253c1 ("drm/imagination: Implement MIPS firmware processor and
MMU support")
Signed-off-by: Randy Dunlap
Cc: Donald Robson
Cc: Maxime Ripard
Cc: Frank Binns
Cc: Matt Coster
Cc: Maarten Lankhorst
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/imagination/pvr_vm_mips.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -- a/drivers/gpu/drm/imagination/pvr_vm_mips.c
b/drivers/gpu/drm/imagination/pvr_vm_mips.c
--- a/drivers/gpu/drm/imagination/pvr_vm_mips.c
+++ b/drivers/gpu/drm/imagination/pvr_vm_mips.c
@@ -46,7 +46,7 @@ pvr_vm_mips_init(struct pvr_device *pvr_
if (!mips_data)
return -ENOMEM;
- for (page_nr = 0; page_nr < ARRAY_SIZE(mips_data->pt_pages); page_nr++)
{
+ for (page_nr = 0; page_nr < PVR_MIPS_PT_PAGE_COUNT; page_nr++) {
mips_data->pt_pages[page_nr] = alloc_page(GFP_KERNEL |
__GFP_ZERO);
if (!mips_data->pt_pages[page_nr]) {
err = -ENOMEM;
@@ -102,7 +102,7 @@ pvr_vm_mips_fini(struct pvr_device *pvr_
int page_nr;
vunmap(mips_data->pt);
- for (page_nr = ARRAY_SIZE(mips_data->pt_pages) - 1; page_nr >= 0;
page_nr--) {
+ for (page_nr = PVR_MIPS_PT_PAGE_COUNT - 1; page_nr >= 0; page_nr--) {
dma_unmap_page(from_pvr_device(pvr_dev)->dev,
mips_data->pt_dma_addr[page_nr], PAGE_SIZE,
DMA_TO_DEVICE);
Re: [PATCH] drm/vmwgfx: Add SVGA_3D_CMD_DEFINE_GB_SURFACE_V4 to command array.
On Mon, Jan 8, 2024 at 4:57 PM Ian Forbes wrote:
>
> Without this definition device errors will display the command name
> as (null) when debug logging is enabled.
>
> Signed-off-by: Ian Forbes
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 36987ef3fc30..472c4821528f 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -3603,6 +3603,8 @@ static const struct vmw_cmd_entry
> vmw_cmd_entries[SVGA_3D_CMD_MAX] = {
> _cmd_dx_bind_streamoutput, true, false, true),
> VMW_CMD_DEF(SVGA_3D_CMD_DX_DEFINE_RASTERIZER_STATE_V2,
> _cmd_dx_so_define, true, false, true),
> + VMW_CMD_DEF(SVGA_3D_CMD_DEFINE_GB_SURFACE_V4,
> + _cmd_invalid, false, false, true),
> };
>
> bool vmw_cmd_describe(const void *buf, u32 *size, char const **cmd)
> --
> 2.34.1
>
Looks good, but in the future you want to both find the change that
initially added SVGA_3D_CMD_DEFINE_GB_SURFACE_V4 and do "dim fixes" to
get the proper "Fixes:..." line to add to the commit description and
either use ./scripts/get_maintainer.pl or at least make sure the
maintainers are included in the patch by hand.
z
Re: [PATCH 2/5] pwm: Drop useless member .of_pwm_n_cells of struct pwm_chip
Hi, On Tue, Jan 9, 2024 at 1:35 PM Uwe Kleine-König wrote: > > Apart from the two of_xlate implementations this member is write-only. > In the of_xlate functions of_pwm_xlate_with_flags() and > of_pwm_single_xlate() it's more sensible to check for args->args_count > because this is what is actually used in the device tree. > > Signed-off-by: Uwe Kleine-König > --- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 - > drivers/pwm/core.c| 22 +++--- > drivers/pwm/pwm-clps711x.c| 1 - > drivers/pwm/pwm-cros-ec.c | 1 - > drivers/pwm/pwm-pxa.c | 4 +--- > include/linux/pwm.h | 2 -- > 6 files changed, 4 insertions(+), 27 deletions(-) I haven't done massive thinking about this, but it seems reasonable to me. I remember being confused about why we needed some of these extra checks ages ago when I looked at this code, so getting rid of them makes sense to me. I've been involved with both the ti-sn65dsi86.c and the pwm-cros-ec.c code and both looks fine to me. I'm an official reviewer for ti-sn65dsi86.c and I'm fairly happy with this tag for it: Acked-by: Douglas Anderson ...and I think it would be fine to go through the PWM tree. If one of the senior drm-misc maintainers disagrees with me, however, then you should listen to them rather than me. -Doug
Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace
Hi Daniel, Please excuse my misconfigured email client. HTML was accidentally enabled in my previous messages, so I'll re-send it for the benefit of mailing lists. þri., 9. jan. 2024 kl. 22:32 skrifaði Daniel Stone : > > On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote: > > + * active color format: > > + * This read-only property tells userspace the color format actually > > used > > + * by the hardware display engine "on the cable" on a connector. The > > chosen > > + * value depends on hardware capabilities, both display engine and > > + * connected monitor. Drivers shall use > > + * drm_connector_attach_active_color_format_property() to install this > > + * property. Possible values are "not applicable", "rgb", "ycbcr444", > > + * "ycbcr422", and "ycbcr420". > > How does userspace determine what's happened without polling? Will it > only change after an `ALLOW_MODESET` commit, and be guaranteed to be > updated after the commit has completed and the event being sent? > Should it send a HOTPLUG event? Other? Userspace does not determine what's happened without polling. The purpose of this property is not for programmatic verification that the preferred property was applied. It is my understanding that it's mostly intended for debugging purposes. It should only change as a consequence of modesetting, although I didn't actually look into what happens if you set the "preferred color format" outside of a modeset. The way I've implemented things in sway, calling the "preferred_signal_format" command triggers a modeset with the "preferred color format" set and calling "get_outputs", immediately queries the "actual color format" and displays it. Regards, Andri
Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace
Hi Daniel, þri., 9. jan. 2024 kl. 22:32 skrifaði Daniel Stone : > On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote: > > + * active color format: > > + * This read-only property tells userspace the color format > actually used > > + * by the hardware display engine "on the cable" on a connector. > The chosen > > + * value depends on hardware capabilities, both display engine and > > + * connected monitor. Drivers shall use > > + * drm_connector_attach_active_color_format_property() to install > this > > + * property. Possible values are "not applicable", "rgb", > "ycbcr444", > > + * "ycbcr422", and "ycbcr420". > > How does userspace determine what's happened without polling? Will it > only change after an `ALLOW_MODESET` commit, and be guaranteed to be > updated after the commit has completed and the event being sent? > Should it send a HOTPLUG event? Other? > Userspace does not determine what's happened without polling. The purpose of this property is not for programmatic verification that the preferred property was applied. It is my understanding that it's mostly intended for debugging purposes. It should only change as a consequence of modesetting, although I didn't actually look into what happens if you set the "preferred color format" outside of a modeset. The way I've implemented things in sway, calling the "preferred_signal_format" command triggers a modeset with the "preferred color format" set and calling "get_outputs", immediately queries the "actual color format" and displays it. Regards, Andri
[PATCH] drm/meson: vclk: fix calculation of 59.94 fractional rates
Playing 4K media with 59.94 fractional rate (typically VP9) causes the screen
to lose
sync with the following error reported in the system log:
[ 89.610280] Fatal Error, invalid HDMI vclk freq 593406
Modetest shows the following:
3840x2160 59.94 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: ,
,
drm calculated value -^
Change the fractional rate calculation to stop DIV_ROUND_CLOSEST rounding down
which
results in vclk freq failing to match correctly.
Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup")
Signed-off-by: Christian Hewitt
---
I'm unable to give a better mathematical description of the fix as I can barely
read
code. The change was inspired by [0] which I chanced upon while looking at how
other
dw-hdmi drivers handle fractional rates.
[0]
https://github.com/torvalds/linux/commit/4f510aa10468954b1da4e94689c38ac6ea8d3627
drivers/gpu/drm/meson/meson_vclk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_vclk.c
b/drivers/gpu/drm/meson/meson_vclk.c
index 2a82119eb58e..2a942dc6a6dc 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -790,13 +790,13 @@ meson_vclk_vic_supported_freq(struct meson_drm *priv,
unsigned int phy_freq,
FREQ_1000_1001(params[i].pixel_freq));
DRM_DEBUG_DRIVER("i = %d phy_freq = %d alt = %d\n",
i, params[i].phy_freq,
-FREQ_1000_1001(params[i].phy_freq/10)*10);
+FREQ_1000_1001(params[i].phy_freq/1000)*1000);
/* Match strict frequency */
if (phy_freq == params[i].phy_freq &&
vclk_freq == params[i].vclk_freq)
return MODE_OK;
/* Match 1000/1001 variant */
- if (phy_freq == (FREQ_1000_1001(params[i].phy_freq/10)*10) &&
+ if (phy_freq == (FREQ_1000_1001(params[i].phy_freq/1000)*1000)
&&
vclk_freq == FREQ_1000_1001(params[i].vclk_freq))
return MODE_OK;
}
@@ -1070,7 +1070,7 @@ void meson_vclk_setup(struct meson_drm *priv, unsigned
int target,
for (freq = 0 ; params[freq].pixel_freq ; ++freq) {
if ((phy_freq == params[freq].phy_freq ||
-phy_freq == FREQ_1000_1001(params[freq].phy_freq/10)*10) &&
+phy_freq ==
FREQ_1000_1001(params[freq].phy_freq/1000)*1000) &&
(vclk_freq == params[freq].vclk_freq ||
vclk_freq == FREQ_1000_1001(params[freq].vclk_freq))) {
if (vclk_freq != params[freq].vclk_freq)
--
2.34.1
Re: [PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace
Hi, On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote: > + * active color format: > + * This read-only property tells userspace the color format actually used > + * by the hardware display engine "on the cable" on a connector. The > chosen > + * value depends on hardware capabilities, both display engine and > + * connected monitor. Drivers shall use > + * drm_connector_attach_active_color_format_property() to install this > + * property. Possible values are "not applicable", "rgb", "ycbcr444", > + * "ycbcr422", and "ycbcr420". How does userspace determine what's happened without polling? Will it only change after an `ALLOW_MODESET` commit, and be guaranteed to be updated after the commit has completed and the event being sent? Should it send a HOTPLUG event? Other? Cheers, Daniel
[PATCH 1/3] selftests/bpf: Update LLVM Phabricator links
reviews.llvm.org was LLVM's Phabricator instances for code review. It
has been abandoned in favor of GitHub pull requests. While the majority
of links in the kernel sources still work because of the work Fangrui
has done turning the dynamic Phabricator instance into a static archive,
there are some issues with that work, so preemptively convert all the
links in the kernel sources to point to the commit on GitHub.
Most of the commits have the corresponding differential review link in
the commit message itself so there should not be any loss of fidelity in
the relevant information.
Additionally, fix a typo in the xdpwall.c print ("LLMV" -> "LLVM") while
in the area.
Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172
Signed-off-by: Nathan Chancellor
---
Cc: a...@kernel.org
Cc: dan...@iogearbox.net
Cc: and...@kernel.org
Cc: myko...@fb.com
Cc: b...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
---
tools/testing/selftests/bpf/README.rst | 32 +++---
tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +-
.../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +-
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/tools/testing/selftests/bpf/README.rst
b/tools/testing/selftests/bpf/README.rst
index cb9b95702ac6..b9a493f66557 100644
--- a/tools/testing/selftests/bpf/README.rst
+++ b/tools/testing/selftests/bpf/README.rst
@@ -115,7 +115,7 @@ the insn 20 undoes map_value addition. It is currently
impossible for the
verifier to understand such speculative pointer arithmetic.
Hence `this patch`__ addresses it on the compiler side. It was committed on
llvm 12.
-__ https://reviews.llvm.org/D85570
+__
https://github.com/llvm/llvm-project/commit/ddf1864ace484035e3cde5e83b3a31ac81e059c6
The corresponding C code
@@ -165,7 +165,7 @@ This is due to a llvm BPF backend bug. `The fix`__
has been pushed to llvm 10.x release branch and will be
available in 10.0.1. The patch is available in llvm 11.0.0 trunk.
-__ https://reviews.llvm.org/D78466
+__
https://github.com/llvm/llvm-project/commit/3cb7e7bf959dcd3b8080986c62e10a75c7af43f0
bpf_verif_scale/loop6.bpf.o test failure with Clang 12
==
@@ -204,7 +204,7 @@ r5(w5) is eventually saved on stack at insn #24 for later
use.
This cause later verifier failure. The bug has been `fixed`__ in
Clang 13.
-__ https://reviews.llvm.org/D97479
+__
https://github.com/llvm/llvm-project/commit/1959ead525b8830cc8a345f45e1c3ef9902d3229
BPF CO-RE-based tests and Clang version
===
@@ -221,11 +221,11 @@ failures:
- __builtin_btf_type_id() [0_, 1_, 2_];
- __builtin_preserve_type_info(), __builtin_preserve_enum_value() [3_, 4_].
-.. _0: https://reviews.llvm.org/D74572
-.. _1: https://reviews.llvm.org/D74668
-.. _2: https://reviews.llvm.org/D85174
-.. _3: https://reviews.llvm.org/D83878
-.. _4: https://reviews.llvm.org/D83242
+.. _0:
https://github.com/llvm/llvm-project/commit/6b01b465388b204d543da3cf49efd6080db094a9
+.. _1:
https://github.com/llvm/llvm-project/commit/072cde03aaa13a2c57acf62d79876bf79aa1919f
+.. _2:
https://github.com/llvm/llvm-project/commit/00602ee7ef0bf6c68d690a2bd729c12b95c95c99
+.. _3:
https://github.com/llvm/llvm-project/commit/6d218b4adb093ff2e9764febbbc89f429412006c
+.. _4:
https://github.com/llvm/llvm-project/commit/6d6750696400e7ce988d66a1a00e1d0cb32815f8
Floating-point tests and Clang version
==
@@ -234,7 +234,7 @@ Certain selftests, e.g. core_reloc, require support for the
floating-point
types, which was introduced in `Clang 13`__. The older Clang versions will
either crash when compiling these tests, or generate an incorrect BTF.
-__ https://reviews.llvm.org/D83289
+__
https://github.com/llvm/llvm-project/commit/a7137b238a07d9399d3ae96c0b461571bd5aa8b2
Kernel function call test and Clang version
===
@@ -248,7 +248,7 @@ Without it, the error from compiling bpf selftests looks
like:
libbpf: failed to find BTF for extern 'tcp_slow_start' [25] section: -2
-__ https://reviews.llvm.org/D93563
+__
https://github.com/llvm/llvm-project/commit/886f9ff53155075bd5f1e994f17b85d1e1b7470c
btf_tag test and Clang version
==
@@ -264,8 +264,8 @@ Without them, the btf_tag selftest will be skipped and you
will observe:
# btf_tag:SKIP
-.. _0: https://reviews.llvm.org/D111588
-.. _1: https://reviews.llvm.org/D99
+.. _0:
https://github.com/llvm/llvm-project/commit/a162b67c98066218d0d00aa13b99afb95d9bb5e6
+.. _1:
https://github.com/llvm/llvm-project/commit/3466e00716e12e32fdb100e3fcfca5c2b3e8d784
Clang dependencies for static linking tests
===
@@ -274,7 +274,7 @@ linked_vars, linked_maps, and linked_funcs tests depend on
`Clang fix`__ to
generate valid BTF information for weak variables. Please make
[PATCH 2/3] arch and include: Update LLVM Phabricator links
reviews.llvm.org was LLVM's Phabricator instances for code review. It has been abandoned in favor of GitHub pull requests. While the majority of links in the kernel sources still work because of the work Fangrui has done turning the dynamic Phabricator instance into a static archive, there are some issues with that work, so preemptively convert all the links in the kernel sources to point to the commit on GitHub. Most of the commits have the corresponding differential review link in the commit message itself so there should not be any loss of fidelity in the relevant information. Link: https://discourse.llvm.org/t/update-on-github-pull-requests/71540/172 Signed-off-by: Nathan Chancellor --- arch/arm64/Kconfig | 4 ++-- arch/riscv/Kconfig | 2 +- arch/riscv/include/asm/ftrace.h | 2 +- include/linux/compiler-clang.h | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 7b071a00425d..3304ba7c6c2a 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -380,7 +380,7 @@ config BROKEN_GAS_INST config BUILTIN_RETURN_ADDRESS_STRIPS_PAC bool # Clang's __builtin_return_adddress() strips the PAC since 12.0.0 - # https://reviews.llvm.org/D75044 + # https://github.com/llvm/llvm-project/commit/2a96f47c5ffca84cd774ad402cacd137f4bf45e2 default y if CC_IS_CLANG && (CLANG_VERSION >= 12) # GCC's __builtin_return_address() strips the PAC since 11.1.0, # and this was backported to 10.2.0, 9.4.0, 8.5.0, but not earlier @@ -2202,7 +2202,7 @@ config STACKPROTECTOR_PER_TASK config UNWIND_PATCH_PAC_INTO_SCS bool "Enable shadow call stack dynamically using code patching" - # needs Clang with https://reviews.llvm.org/D111780 incorporated + # needs Clang with https://github.com/llvm/llvm-project/commit/de07cde67b5d205d58690be012106022aea6d2b3 incorporated depends on CC_IS_CLANG && CLANG_VERSION >= 15 depends on ARM64_PTR_AUTH_KERNEL && CC_HAS_BRANCH_PROT_PAC_RET depends on SHADOW_CALL_STACK diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index cd4c9a204d08..f7453eba0b62 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -291,7 +291,7 @@ config AS_HAS_INSN def_bool $(as-instr,.insn r 51$(comma) 0$(comma) 0$(comma) t0$(comma) t0$(comma) zero) config AS_HAS_OPTION_ARCH - # https://reviews.llvm.org/D123515 + # https://github.com/llvm/llvm-project/commit/9e8ed3403c191ab9c4903e8eeb8f732ff8a43cb4 def_bool y depends on $(as-instr, .option arch$(comma) +m) depends on !$(as-instr, .option arch$(comma) -i) diff --git a/arch/riscv/include/asm/ftrace.h b/arch/riscv/include/asm/ftrace.h index 2b2f5df7ef2c..3f526404a718 100644 --- a/arch/riscv/include/asm/ftrace.h +++ b/arch/riscv/include/asm/ftrace.h @@ -15,7 +15,7 @@ /* * Clang prior to 13 had "mcount" instead of "_mcount": - * https://reviews.llvm.org/D98881 + * https://github.com/llvm/llvm-project/commit/ef58ae86ba778ed7d01cd3f6bd6d08f943abab44 */ #if defined(CONFIG_CC_IS_GCC) || CONFIG_CLANG_VERSION >= 13 #define MCOUNT_NAME _mcount diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h index ddab1ef22bee..f0a47afef125 100644 --- a/include/linux/compiler-clang.h +++ b/include/linux/compiler-clang.h @@ -9,7 +9,7 @@ * Clang prior to 17 is being silly and considers many __cleanup() variables * as unused (because they are, their sole purpose is to go out of scope). * - * https://reviews.llvm.org/D152180 + * https://github.com/llvm/llvm-project/commit/877210faa447f4cc7db87812f8ed80e398fedd61 */ #undef __cleanup #define __cleanup(func) __maybe_unused __attribute__((__cleanup__(func))) -- 2.43.0
[PATCH 3/3] treewide: Update LLVM Bugzilla links
LLVM moved their issue tracker from their own Bugzilla instance to
GitHub issues. While all of the links are still valid, they may not
necessarily show the most up to date information around the issues, as
all updates will occur on GitHub, not Bugzilla.
Another complication is that the Bugzilla issue number is not always the
same as the GitHub issue number. Thankfully, LLVM maintains this mapping
through two shortlinks:
https://llvm.org/bz -> https://bugs.llvm.org/show_bug.cgi?id=
https://llvm.org/pr ->
https://github.com/llvm/llvm-project/issues/
Switch all "https://bugs.llvm.org/show_bug.cgi?id=" links to the
"https://llvm.org/pr" shortlink so that the links show the most up
to date information. Each migrated issue links back to the Bugzilla
entry, so there should be no loss of fidelity of information here.
Signed-off-by: Nathan Chancellor
---
arch/powerpc/Makefile | 4 ++--
arch/powerpc/kvm/book3s_hv_nested.c | 2 +-
arch/s390/include/asm/ftrace.h | 2 +-
arch/x86/power/Makefile | 2 +-
crypto/blake2b_generic.c| 2 +-
drivers/firmware/efi/libstub/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c| 2 +-
drivers/media/test-drivers/vicodec/codec-fwht.c | 2 +-
drivers/regulator/Kconfig | 2 +-
include/asm-generic/vmlinux.lds.h | 2 +-
lib/Kconfig.kasan | 2 +-
lib/raid6/Makefile | 2 +-
lib/stackinit_kunit.c | 2 +-
mm/slab_common.c| 2 +-
net/bridge/br_multicast.c | 2 +-
security/Kconfig| 2 +-
16 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f19dbaa1d541..cd6aaa45f355 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -133,11 +133,11 @@ CFLAGS-$(CONFIG_PPC64)+= $(call
cc-option,-mno-pointers-to-nested-functions)
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mlong-double-128)
# Clang unconditionally reserves r2 on ppc32 and does not support the flag
-# https://bugs.llvm.org/show_bug.cgi?id=39555
+# https://llvm.org/pr39555
CFLAGS-$(CONFIG_PPC32) := $(call cc-option, -ffixed-r2)
# Clang doesn't support -mmultiple / -mno-multiple
-# https://bugs.llvm.org/show_bug.cgi?id=39556
+# https://llvm.org/pr39556
CFLAGS-$(CONFIG_PPC32) += $(call cc-option, $(MULTIPLEWORD))
CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata)
diff --git a/arch/powerpc/kvm/book3s_hv_nested.c
b/arch/powerpc/kvm/book3s_hv_nested.c
index 3b658b8696bc..3f5970f74c6b 100644
--- a/arch/powerpc/kvm/book3s_hv_nested.c
+++ b/arch/powerpc/kvm/book3s_hv_nested.c
@@ -55,7 +55,7 @@ void kvmhv_save_hv_regs(struct kvm_vcpu *vcpu, struct
hv_guest_state *hr)
hr->dawrx1 = vcpu->arch.dawrx1;
}
-/* Use noinline_for_stack due to https://bugs.llvm.org/show_bug.cgi?id=49610 */
+/* Use noinline_for_stack due to https://llvm.org/pr49610 */
static noinline_for_stack void byteswap_pt_regs(struct pt_regs *regs)
{
unsigned long *addr = (unsigned long *) regs;
diff --git a/arch/s390/include/asm/ftrace.h b/arch/s390/include/asm/ftrace.h
index 5a82b08f03cd..621f23d5ae30 100644
--- a/arch/s390/include/asm/ftrace.h
+++ b/arch/s390/include/asm/ftrace.h
@@ -9,7 +9,7 @@
#ifndef __ASSEMBLY__
#ifdef CONFIG_CC_IS_CLANG
-/* https://bugs.llvm.org/show_bug.cgi?id=41424 */
+/* https://llvm.org/pr41424 */
#define ftrace_return_address(n) 0UL
#else
#define ftrace_return_address(n) __builtin_return_address(n)
diff --git a/arch/x86/power/Makefile b/arch/x86/power/Makefile
index 379777572bc9..e0cd7afd5302 100644
--- a/arch/x86/power/Makefile
+++ b/arch/x86/power/Makefile
@@ -5,7 +5,7 @@
CFLAGS_cpu.o := -fno-stack-protector
# Clang may incorrectly inline functions with stack protector enabled into
-# __restore_processor_state(): https://bugs.llvm.org/show_bug.cgi?id=47479
+# __restore_processor_state(): https://llvm.org/pr47479
CFLAGS_REMOVE_cpu.o := $(CC_FLAGS_LTO)
obj-$(CONFIG_PM_SLEEP) += cpu.o
diff --git a/crypto/blake2b_generic.c b/crypto/blake2b_generic.c
index 6704c0355889..32e380b714b6 100644
--- a/crypto/blake2b_generic.c
+++ b/crypto/blake2b_generic.c
@@ -102,7 +102,7 @@ static void blake2b_compress_one_generic(struct
blake2b_state *S,
ROUND(10);
ROUND(11);
#ifdef CONFIG_CC_IS_CLANG
-#pragma nounroll /* https://bugs.llvm.org/show_bug.cgi?id=45803 */
+#pragma nounroll /* https://llvm.org/pr45803 */
#endif
for (i = 0; i < 8; ++i)
S->h[i] = S->h[i] ^ v[i] ^ v[i + 8];
diff --git a/drivers/firmware/efi/libstub/Makefile
b/drivers/firmware/efi/libstub/Makefile
index 06964a3c130f..a223bd10564b 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -105,7 +105,7 @@ lib-y
[PATCH 0/3] Update LLVM Phabricator and Bugzilla links
This series updates all instances of LLVM Phabricator and Bugzilla links to point to GitHub commits directly and LLVM's Bugzilla to GitHub issue shortlinks respectively. I split up the Phabricator patch into BPF selftests and the rest of the kernel in case the BPF folks want to take it separately from the rest of the series, there are obviously no dependency issues in that case. The Bugzilla change was mechanical enough and should have no conflicts. I am aiming this at Andrew and CC'ing other lists, in case maintainers want to chime in, but I think this is pretty uncontroversial (famous last words...). --- Nathan Chancellor (3): selftests/bpf: Update LLVM Phabricator links arch and include: Update LLVM Phabricator links treewide: Update LLVM Bugzilla links arch/arm64/Kconfig | 4 +-- arch/powerpc/Makefile | 4 +-- arch/powerpc/kvm/book3s_hv_nested.c| 2 +- arch/riscv/Kconfig | 2 +- arch/riscv/include/asm/ftrace.h| 2 +- arch/s390/include/asm/ftrace.h | 2 +- arch/x86/power/Makefile| 2 +- crypto/blake2b_generic.c | 2 +- drivers/firmware/efi/libstub/Makefile | 2 +- drivers/gpu/drm/amd/amdgpu/sdma_v4_4_2.c | 2 +- drivers/media/test-drivers/vicodec/codec-fwht.c| 2 +- drivers/regulator/Kconfig | 2 +- include/asm-generic/vmlinux.lds.h | 2 +- include/linux/compiler-clang.h | 2 +- lib/Kconfig.kasan | 2 +- lib/raid6/Makefile | 2 +- lib/stackinit_kunit.c | 2 +- mm/slab_common.c | 2 +- net/bridge/br_multicast.c | 2 +- security/Kconfig | 2 +- tools/testing/selftests/bpf/README.rst | 32 +++--- tools/testing/selftests/bpf/prog_tests/xdpwall.c | 2 +- .../selftests/bpf/progs/test_core_reloc_type_id.c | 2 +- 23 files changed, 40 insertions(+), 40 deletions(-) --- base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a change-id: 20240109-update-llvm-links-d03f9d649e1e Best regards, -- Nathan Chancellor
[PATCH 4/7] drm/i915/display: Add handling for new "active color format" property
From: Werner Sembach
This commit implements the "active color format" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
Signed-off-by: Andri Yngvason
Tested-by: Andri Yngvason
---
drivers/gpu/drm/i915/display/intel_display.c | 33
drivers/gpu/drm/i915/display/intel_dp.c | 7 +++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++
drivers/gpu/drm/i915/display/intel_hdmi.c| 4 ++-
4 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index df582ff81b45f..79cc258db8f09 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7167,6 +7167,21 @@ static void
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
}
}
+static int convert_intel_output_format_into_drm_color_format(enum
intel_output_format output_format)
+{
+ switch (output_format) {
+ case INTEL_OUTPUT_FORMAT_RGB:
+ return DRM_COLOR_FORMAT_RGB444;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ return DRM_COLOR_FORMAT_YCBCR420;
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ return DRM_COLOR_FORMAT_YCBCR444;
+ default:
+ break;
+ }
+ return 0;
+}
+
static void intel_atomic_commit_tail(struct intel_atomic_state *state)
{
struct drm_device *dev = state->base.dev;
@@ -7438,6 +7453,9 @@ int intel_atomic_commit(struct drm_device *dev, struct
drm_atomic_state *_state,
{
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
+ int i;
int ret = 0;
state->wakeref = intel_runtime_pm_get(_priv->runtime_pm);
@@ -7506,6 +7524,21 @@ int intel_atomic_commit(struct drm_device *dev, struct
drm_atomic_state *_state,
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
+ /* Extract information from crtc to communicate it to userspace as
connector properties */
+ for_each_new_connector_in_state(>base, connector,
new_conn_state, i) {
+ struct intel_crtc *crtc = to_intel_crtc(new_conn_state->crtc);
+
+ if (crtc) {
+ struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+
+
drm_connector_set_active_color_format_property(connector,
+
convert_intel_output_format_into_drm_color_format(
+ new_crtc_state->output_format));
+ } else
+
drm_connector_set_active_color_format_property(connector, 0);
+ }
+
drm_atomic_state_get(>base);
INIT_WORK(>base.commit_work, intel_atomic_commit_work);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 62ce92772367f..c40fe8a847614 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5910,10 +5910,13 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
- if (HAS_GMCH(dev_priv))
+ if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
- else if (DISPLAY_VER(dev_priv) >= 5)
+ drm_connector_attach_active_color_format_property(connector);
+ } else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ drm_connector_attach_active_color_format_property(connector);
+ }
/* Register HDMI colorspace for case of lspcon */
if
(intel_bios_encoder_is_lspcon(dp_to_dig_port(intel_dp)->base.devdata)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index aa10612626136..e7574ca0604e6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1210,6 +1210,11 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
drm_dbg_kms(_priv->drm, "[%s:%d] HDCP MST init failed,
skipping.\n",
connector->name, connector->base.id);
+ connector->active_color_format_property =
+ intel_dp->attached_connector->base.active_color_format_property;
+ if (connector->active_color_format_property)
+ drm_connector_attach_active_color_format_property(connector);
+
return connector;
err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index
[PATCH 0/7] New DRM properties for output color format
This is a subset of patches, originally submitted by Werner Sembach titled: New uAPI drm properties for color management [1] I've rebased against the current master branch, made modifications where needed, and tested with both HDMI and DP on both Intel and AMD hardware, using modified sway [2] and wlroots [3]. The original patch set added the following properties: - active bpc - active color format - active color range - preferred color format and consolidated "Broadcast RGB" into a single property. I've elected to only include active and preferred color format in this patch set as I've very little interest in the other properties and, hopefully, this will be easier for others to review. [1]: https://lore.kernel.org/dri-devel/20210630151018.330354-1-...@tuxedocomputers.com/ [2]: https://github.com/swaywm/sway/pull/7903 [3]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4509 Werner Sembach (7): drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check drm/uAPI: Add "active color format" drm property as feedback for userspace drm/amd/display: Add handling for new "active color format" property drm/i915/display: Add handling for new "active color format" property drm/uAPI: Add "preferred color format" drm property as setting for userspace drm/amd/display: Add handling for new "preferred color format" property drm/i915/display: Add handling for new "preferred color format" property .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 75 ++-- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 8 ++ drivers/gpu/drm/drm_atomic_helper.c | 4 + drivers/gpu/drm/drm_atomic_uapi.c | 4 + drivers/gpu/drm/drm_connector.c | 111 ++ drivers/gpu/drm/i915/display/intel_display.c | 33 ++ drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++ drivers/gpu/drm/i915/display/intel_hdmi.c | 16 ++- include/drm/drm_connector.h | 27 + 10 files changed, 289 insertions(+), 22 deletions(-) base-commit: 1f874787ed9a2d78ed59cb21d0d90ac0178eceb0 -- 2.43.0
[PATCH 6/7] drm/amd/display: Add handling for new "preferred color format" property
From: Werner Sembach
This commit implements the "preferred color format" drm property for the
AMD GPU driver.
Signed-off-by: Werner Sembach
Signed-off-by: Andri Yngvason
Tested-by: Andri Yngvason
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 28 insertions(+), 6 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 b44d06c3b1706..262d420877c91 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5522,15 +5522,32 @@ static void
fill_stream_properties_from_drm_display_mode(
timing_out->h_border_right = 0;
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
- /* TODO: un-hardcode */
- if (drm_mode_is_420_only(info, mode_in)
- || (drm_mode_is_420_also(info, mode_in) &&
aconnector->force_yuv420_output))
+
+ if (connector_state
+ && (connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCBCR420
+ || aconnector->force_yuv420_output) &&
drm_mode_is_420(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
- else if ((connector->display_info.color_formats &
DRM_COLOR_FORMAT_YCBCR444)
- && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+ else if (connector_state
+ && connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCBCR444
+ && connector->display_info.color_formats &
DRM_COLOR_FORMAT_YCBCR444)
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
- else
+ else if (connector_state
+ && connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_RGB444
+ && !drm_mode_is_420_only(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
+ else
+ /*
+* connector_state->preferred_color_format not possible
+* || connector_state->preferred_color_format == 0 (auto)
+* || connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCBCR422
+*/
+ if (drm_mode_is_420_only(info, mode_in))
+ timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
+ else if ((connector->display_info.color_formats &
DRM_COLOR_FORMAT_YCBCR444)
+ && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+ timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
+ else
+ timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
timing_out->timing_3d_format = TIMING_3D_FORMAT_NONE;
timing_out->display_color_depth = convert_color_depth_from_display_info(
@@ -7456,6 +7473,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
if (!aconnector->mst_root) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+
drm_connector_attach_preferred_color_format_property(>base);
drm_connector_attach_active_color_format_property(>base);
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index a4d1b3ea8f81c..dc8cea0ac2c11 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -600,6 +600,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 8, 16);
+ connector->preferred_color_format_property =
master->base.preferred_color_format_property;
+ if (connector->preferred_color_format_property)
+
drm_connector_attach_preferred_color_format_property(>base);
+
connector->active_color_format_property =
master->base.active_color_format_property;
if (connector->active_color_format_property)
drm_connector_attach_active_color_format_property(>base);
--
2.43.0
[PATCH 3/7] drm/amd/display: Add handling for new "active color format" property
From: Werner Sembach
This commit implements the "active color format" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
Signed-off-by: Andri Yngvason
Tested-by: Andri Yngvason
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 ++
2 files changed, 45 insertions(+), 1 deletion(-)
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 10e041a3b2545..b44d06c3b1706 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6882,6 +6882,24 @@ int convert_dc_color_depth_into_bpc(enum dc_color_depth
display_color_depth)
return 0;
}
+static int convert_dc_pixel_encoding_into_drm_color_format(
+ enum dc_pixel_encoding display_pixel_encoding)
+{
+ switch (display_pixel_encoding) {
+ case PIXEL_ENCODING_RGB:
+ return DRM_COLOR_FORMAT_RGB444;
+ case PIXEL_ENCODING_YCBCR422:
+ return DRM_COLOR_FORMAT_YCBCR422;
+ case PIXEL_ENCODING_YCBCR444:
+ return DRM_COLOR_FORMAT_YCBCR444;
+ case PIXEL_ENCODING_YCBCR420:
+ return DRM_COLOR_FORMAT_YCBCR420;
+ default:
+ break;
+ }
+ return 0;
+}
+
static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state
*conn_state)
@@ -7436,8 +7454,10 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
- if (!aconnector->mst_root)
+ if (!aconnector->mst_root) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+
drm_connector_attach_active_color_format_property(>base);
+ }
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc =
aconnector->base.state->max_bpc;
@@ -8969,6 +8989,26 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
kfree(dummy_updates);
}
+ /* Extract information from crtc to communicate it to userspace as
connector properties */
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
+ struct drm_crtc *crtc = new_con_state->crtc;
+ struct dc_stream_state *stream;
+
+ if (crtc) {
+ new_crtc_state = drm_atomic_get_new_crtc_state(state,
crtc);
+ dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+ stream = dm_new_crtc_state->stream;
+
+ if (stream) {
+
drm_connector_set_active_color_format_property(connector,
+
convert_dc_pixel_encoding_into_drm_color_format(
+
dm_new_crtc_state->stream->timing.pixel_encoding));
+ }
+ } else {
+
drm_connector_set_active_color_format_property(connector, 0);
+ }
+ }
+
/**
* Enable interrupts for CRTCs that are newly enabled or went through
* a modeset. It was intentionally deferred until after the front end
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 11da0eebee6c4..a4d1b3ea8f81c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -600,6 +600,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 8, 16);
+ connector->active_color_format_property =
master->base.active_color_format_property;
+ if (connector->active_color_format_property)
+
drm_connector_attach_active_color_format_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
--
2.43.0
[PATCH 1/7] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
From: Werner Sembach Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() && force_yuv420_output case. Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI, there is no reason to use RGB when the display reports drm_mode_is_420_only() even on a non HDMI connection. This patch also moves both checks in the same if-case. This eliminates an extra else-if-case. Signed-off-by: Werner Sembach Signed-off-by: Andri Yngvason Tested-by: Andri Yngvason --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 + 1 file changed, 1 insertion(+), 4 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 c8c00c2a5224a..10e041a3b2545 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5524,10 +5524,7 @@ static void fill_stream_properties_from_drm_display_mode( timing_out->v_border_bottom = 0; /* TODO: un-hardcode */ if (drm_mode_is_420_only(info, mode_in) - && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) - timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; - else if (drm_mode_is_420_also(info, mode_in) - && aconnector->force_yuv420_output) + || (drm_mode_is_420_also(info, mode_in) && aconnector->force_yuv420_output)) timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR444) && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) -- 2.43.0
[PATCH 7/7] drm/i915/display: Add handling for new "preferred color format" property
From: Werner Sembach
This commit implements the "preferred color format" drm property for the
Intel GPU driver.
Signed-off-by: Werner Sembach
Co-developed-by: Andri Yngvason
Signed-off-by: Andri Yngvason
Tested-by: Andri Yngvason
---
drivers/gpu/drm/i915/display/intel_dp.c | 16 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +---
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c40fe8a847614..f241798660d0b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2698,21 +2698,23 @@ intel_dp_compute_output_format(struct intel_encoder
*encoder,
struct intel_connector *connector = intel_dp->attached_connector;
const struct drm_display_info *info = >base.display_info;
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
- bool ycbcr_420_only;
+ bool ycbcr_420_output;
int ret;
- ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode);
+ ycbcr_420_output = drm_mode_is_420_only(info, adjusted_mode) ||
+ (conn_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCBCR420 &&
+ drm_mode_is_420_also(>base.display_info,
adjusted_mode));
- if (ycbcr_420_only && !connector->base.ycbcr_420_allowed) {
+ crtc_state->sink_format = ycbcr_420_output ?
INTEL_OUTPUT_FORMAT_YCBCR420 :
+INTEL_OUTPUT_FORMAT_RGB;
+
+ if (ycbcr_420_output && !connector->base.ycbcr_420_allowed) {
drm_dbg_kms(>drm,
"YCbCr 4:2:0 mode but YCbCr 4:2:0 output not
possible. Falling back to RGB.\n");
crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
- } else {
- crtc_state->sink_format = intel_dp_sink_format(connector,
adjusted_mode);
}
crtc_state->output_format = intel_dp_output_format(connector,
crtc_state->sink_format);
-
ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
respect_downstream_limits);
if (ret) {
@@ -5912,9 +5914,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_broadcast_rgb_property(connector);
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
+ drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
} else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index e7574ca0604e6..4a850eb9b8d4d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -1210,6 +1210,11 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
drm_dbg_kms(_priv->drm, "[%s:%d] HDCP MST init failed,
skipping.\n",
connector->name, connector->base.id);
+ connector->preferred_color_format_property =
+
intel_dp->attached_connector->base.preferred_color_format_property;
+ if (connector->preferred_color_format_property)
+ drm_connector_attach_preferred_color_format_property(connector);
+
connector->active_color_format_property =
intel_dp->attached_connector->base.active_color_format_property;
if (connector->active_color_format_property)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index ce0221f90de92..3030589d245d7 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2214,19 +2214,24 @@ static int intel_hdmi_compute_output_format(struct
intel_encoder *encoder,
const struct drm_display_mode *adjusted_mode =
_state->hw.adjusted_mode;
const struct drm_display_info *info = >base.display_info;
struct drm_i915_private *i915 = to_i915(connector->base.dev);
- bool ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode);
+ bool ycbcr_420_output;
int ret;
+ ycbcr_420_output = drm_mode_is_420_only(info, adjusted_mode) ||
+ (conn_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCBCR420 &&
+ drm_mode_is_420_also(>base.display_info,
adjusted_mode));
+
crtc_state->sink_format =
-
[PATCH 5/7] drm/uAPI: Add "preferred color format" drm property as setting for userspace
From: Werner Sembach
Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr420
In theory the auto option should choose the best available option for the
current setup, but because of bad internal conversion some monitors look
better with rgb and some with ycbcr444.
Also, because of bad shielded connectors and/or cables, it might be
preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
for a signal that is less deceptible to interference.
In the future, automatic color calibration for screens might also depend on
this option being available.
Signed-off-by: Werner Sembach
Reported-by: Dan Carpenter
Signed-off-by: Andri Yngvason
Tested-by: Andri Yngvason
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 50 -
include/drm/drm_connector.h | 17 ++
4 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 68ffcc0b00dca..745a43d9c5da3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -707,6 +707,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->preferred_color_format !=
+ new_connector_state->preferred_color_format)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 98d3b10c08ae1..eba5dea1249e5 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->max_requested_bpc = val;
} else if (property == connector->privacy_screen_sw_state_property) {
state->privacy_screen_sw_state = val;
+ } else if (property == connector->preferred_color_format_property) {
+ state->preferred_color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -881,6 +883,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->max_requested_bpc;
} else if (property == connector->privacy_screen_sw_state_property) {
*val = state->privacy_screen_sw_state;
+ } else if (property == connector->preferred_color_format_property) {
+ *val = state->preferred_color_format;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 30d62e505d188..4de48a38792cf 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1061,6 +1061,14 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
};
+static const struct drm_prop_enum_list drm_preferred_color_format_enum_list[]
= {
+ { 0, "auto" },
+ { DRM_COLOR_FORMAT_RGB444, "rgb" },
+ { DRM_COLOR_FORMAT_YCBCR444, "ycbcr444" },
+ { DRM_COLOR_FORMAT_YCBCR422, "ycbcr422" },
+ { DRM_COLOR_FORMAT_YCBCR420, "ycbcr420" },
+};
+
static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
{ 0, "not applicable" },
{ DRM_COLOR_FORMAT_RGB444, "rgb" },
@@ -1398,11 +1406,20 @@ static const u32 dp_colorspaces =
* drm_connector_attach_max_bpc_property() to create and attach the
* property to the connector during initialization.
*
+ * preferred color format:
+ * This property is used by userspace to change the used color format. When
+ * used the driver will use the selected format if valid for the hardware,
+ * sink, and current resolution and refresh rate combination. Drivers to
+ * use the function drm_connector_attach_preferred_color_format_property()
+ * to create and attach the property to the connector during
+ * initialization. Possible values are "auto", "rgb", "ycbcr444",
+ * "ycbcr422", and "ycbcr420".
+ *
* active color format:
* This read-only property
[PATCH 2/7] drm/uAPI: Add "active color format" drm property as feedback for userspace
From: Werner Sembach
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor, the GPU, and the connection used and what the default
behaviour of the used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915
prefers RGB). This property helps eliminating the guessing on this point.
In the future, automatic color calibration for screens might also depend on
this information being available.
Signed-off-by: Werner Sembach
Signed-off-by: Andri Yngvason
Tested-by: Andri Yngvason
---
drivers/gpu/drm/drm_connector.c | 63 +
include/drm/drm_connector.h | 10 ++
2 files changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c3725086f4132..30d62e505d188 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1061,6 +1061,14 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
};
+static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
+ { 0, "not applicable" },
+ { DRM_COLOR_FORMAT_RGB444, "rgb" },
+ { DRM_COLOR_FORMAT_YCBCR444, "ycbcr444" },
+ { DRM_COLOR_FORMAT_YCBCR422, "ycbcr422" },
+ { DRM_COLOR_FORMAT_YCBCR420, "ycbcr420" },
+};
+
DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
drm_dp_subconnector_enum_list)
@@ -1390,6 +1398,15 @@ static const u32 dp_colorspaces =
* drm_connector_attach_max_bpc_property() to create and attach the
* property to the connector during initialization.
*
+ * active color format:
+ * This read-only property tells userspace the color format actually used
+ * by the hardware display engine "on the cable" on a connector. The chosen
+ * value depends on hardware capabilities, both display engine and
+ * connected monitor. Drivers shall use
+ * drm_connector_attach_active_color_format_property() to install this
+ * property. Possible values are "not applicable", "rgb", "ycbcr444",
+ * "ycbcr422", and "ycbcr420".
+ *
* Connectors also have one standardized atomic property:
*
* CRTC_ID:
@@ -2451,6 +2468,52 @@ int drm_connector_attach_max_bpc_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
+/**
+ * drm_connector_attach_active_color_format_property - attach "active color
format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to check the applied color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_format_property(struct drm_connector
*connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop;
+
+ if (!connector->active_color_format_property) {
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
"active color format",
+
drm_active_color_format_enum_list,
+
ARRAY_SIZE(drm_active_color_format_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ connector->active_color_format_property = prop;
+ }
+
+ drm_object_attach_property(>base, prop, 0);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);
+
+/**
+ * drm_connector_set_active_color_format_property - sets the active color
format property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_format: color format for the connector currently active "on
the cable"
+ *
+ * Should be used by atomic drivers to update the active color format over a
connector.
+ */
+void drm_connector_set_active_color_format_property(struct drm_connector
*connector,
+ u32 active_color_format)
+{
+ drm_object_property_set_value(>base,
connector->active_color_format_property,
+ active_color_format);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
+
/**
* drm_connector_attach_hdr_output_metadata_property - attach
"HDR_OUTPUT_METADA" property
* @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f4..9ae73cfdceeb1 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1699,6 +1699,12 @@ struct drm_connector {
*/
struct drm_property *privacy_screen_hw_state_property;
+ /**
+* @active_color_format_property: Default connector property for the
+* active color
Lenovo b40-30 i915.invert_brightness
Dear maintainers, I have a Lenovo b40-30 that I have been running with nomodeset for a while. The issue was that it needed invert_brightness. Here are the requested IDs: 0f31, 17aa, 3986 :). N.B.: I am not subscribed, please Cc me when replying. Best regards, Cédric
Re: [DO NOT MERGE v6 26/37] dt-bindings: vendor-prefixes: Add smi
Hello, not a complete review, I just note that there is a duplicate space in the Subject. You might want to fix for the next patch round. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[PATCH 2/5] pwm: Drop useless member .of_pwm_n_cells of struct pwm_chip
Apart from the two of_xlate implementations this member is write-only.
In the of_xlate functions of_pwm_xlate_with_flags() and
of_pwm_single_xlate() it's more sensible to check for args->args_count
because this is what is actually used in the device tree.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 -
drivers/pwm/core.c| 22 +++---
drivers/pwm/pwm-clps711x.c| 1 -
drivers/pwm/pwm-cros-ec.c | 1 -
drivers/pwm/pwm-pxa.c | 4 +---
include/linux/pwm.h | 2 --
6 files changed, 4 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index c45c07840f64..02d9449956e5 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -1591,7 +1591,6 @@ static int ti_sn_pwm_probe(struct auxiliary_device *adev,
pdata->pchip.ops = _sn_pwm_ops;
pdata->pchip.npwm = 1;
pdata->pchip.of_xlate = of_pwm_single_xlate;
- pdata->pchip.of_pwm_n_cells = 1;
return pwmchip_add(>pchip);
}
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f2728ee787d7..31f210872a07 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -107,9 +107,6 @@ of_pwm_xlate_with_flags(struct pwm_chip *chip, const struct
of_phandle_args *arg
{
struct pwm_device *pwm;
- if (chip->of_pwm_n_cells < 2)
- return ERR_PTR(-EINVAL);
-
/* flags in the third cell are optional */
if (args->args_count < 2)
return ERR_PTR(-EINVAL);
@@ -124,10 +121,8 @@ of_pwm_xlate_with_flags(struct pwm_chip *chip, const
struct of_phandle_args *arg
pwm->args.period = args->args[1];
pwm->args.polarity = PWM_POLARITY_NORMAL;
- if (chip->of_pwm_n_cells >= 3) {
- if (args->args_count > 2 && args->args[2] &
PWM_POLARITY_INVERTED)
- pwm->args.polarity = PWM_POLARITY_INVERSED;
- }
+ if (args->args_count > 2 && args->args[2] & PWM_POLARITY_INVERTED)
+ pwm->args.polarity = PWM_POLARITY_INVERSED;
return pwm;
}
@@ -138,9 +133,6 @@ of_pwm_single_xlate(struct pwm_chip *chip, const struct
of_phandle_args *args)
{
struct pwm_device *pwm;
- if (chip->of_pwm_n_cells < 1)
- return ERR_PTR(-EINVAL);
-
/* validate that one cell is specified, optionally with flags */
if (args->args_count != 1 && args->args_count != 2)
return ERR_PTR(-EINVAL);
@@ -164,16 +156,8 @@ static void of_pwmchip_add(struct pwm_chip *chip)
if (!chip->dev || !chip->dev->of_node)
return;
- if (!chip->of_xlate) {
- u32 pwm_cells;
-
- if (of_property_read_u32(chip->dev->of_node, "#pwm-cells",
-_cells))
- pwm_cells = 2;
-
+ if (!chip->of_xlate)
chip->of_xlate = of_pwm_xlate_with_flags;
- chip->of_pwm_n_cells = pwm_cells;
- }
of_node_get(chip->dev->of_node);
}
diff --git a/drivers/pwm/pwm-clps711x.c b/drivers/pwm/pwm-clps711x.c
index 42179b3f7ec3..06562d4bb963 100644
--- a/drivers/pwm/pwm-clps711x.c
+++ b/drivers/pwm/pwm-clps711x.c
@@ -103,7 +103,6 @@ static int clps711x_pwm_probe(struct platform_device *pdev)
priv->chip.dev = >dev;
priv->chip.npwm = 2;
priv->chip.of_xlate = clps711x_pwm_xlate;
- priv->chip.of_pwm_n_cells = 1;
spin_lock_init(>lock);
diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
index 5fe303b8656d..339cedf3a7b1 100644
--- a/drivers/pwm/pwm-cros-ec.c
+++ b/drivers/pwm/pwm-cros-ec.c
@@ -279,7 +279,6 @@ static int cros_ec_pwm_probe(struct platform_device *pdev)
chip->dev = dev;
chip->ops = _ec_pwm_ops;
chip->of_xlate = cros_ec_pwm_xlate;
- chip->of_pwm_n_cells = 1;
if (ec_pwm->use_pwm_type) {
chip->npwm = CROS_EC_PWM_DT_COUNT;
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index 76685f926c75..61b74fa1d348 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -180,10 +180,8 @@ static int pwm_probe(struct platform_device *pdev)
pc->chip.ops = _pwm_ops;
pc->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1;
- if (IS_ENABLED(CONFIG_OF)) {
+ if (IS_ENABLED(CONFIG_OF))
pc->chip.of_xlate = of_pwm_single_xlate;
- pc->chip.of_pwm_n_cells = 1;
- }
pc->mmio_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(pc->mmio_base))
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index fcc2c4496f73..8ffe9ae7a23a 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -271,7 +271,6 @@ struct pwm_ops {
* @id: unique number of this PWM chip
* @npwm: number of PWMs controlled by this chip
* @of_xlate: request a PWM
[PATCH 0/5] pwm: Some improvements around .of_xlate()
Hello, the first patch is a fix for an out-of-bounds access and so should probably go in quickly. The other changes are merge window material. Best regards Uwe Uwe Kleine-König (5): pwm: Fix out-of-bounds access in of_pwm_single_xlate() pwm: Drop useless member .of_pwm_n_cells of struct pwm_chip pwm: Let the of_xlate callbacks accept references without period pwm: clps711x: Drop custom .of_xlate() callback pwm: Drop duplicate check against chip->npwm in of_pwm_xlate_with_flags() drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 - drivers/pwm/core.c| 45 +++ drivers/pwm/pwm-clps711x.c| 11 --- drivers/pwm/pwm-cros-ec.c | 1 - drivers/pwm/pwm-pxa.c | 4 +-- include/linux/pwm.h | 2 -- 6 files changed, 13 insertions(+), 51 deletions(-) base-commit: d73f444d06fb8a42a5c0623453f3ea1fe9880229 -- 2.43.0
[PATCH] drm/msm/a6xx: set highest_bank_bit to 13 for a610
During the testing of Gnome on Qualcomm Robotics platform screen
corruption has been observed. Lowering GPU's highest_bank_bit from 14 to
13 seems to fix the screen corruption.
Note, the MDSS and DPU drivers use HBB=1 (which maps to the
highest_bank_bit = 14). So this change merely works around the UBWC
swizzling issue on this platform until the real cause is found.
Fixes: e7fc9398e608 ("drm/msm/a6xx: Add A610 support")
Signed-off-by: Dmitry Baryshkov
---
The photo of screen corruption:
https://photos.app.goo.gl/k4MPzpBKPUD3AKR37
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c0bc924cd302..c9c55e2ea584 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1287,7 +1287,7 @@ static void a6xx_calc_ubwc_config(struct adreno_gpu *gpu)
gpu->ubwc_config.highest_bank_bit = 15;
if (adreno_is_a610(gpu)) {
- gpu->ubwc_config.highest_bank_bit = 14;
+ gpu->ubwc_config.highest_bank_bit = 13;
gpu->ubwc_config.min_acc_len = 1;
gpu->ubwc_config.ubwc_mode = 1;
}
--
2.39.2
Re: [PATCH 4/5] clk: sunxi-ng: a64: Add constraints on PLL-VIDEO0's n/m ratio
Dne nedelja, 31. december 2023 ob 10:10:40 CET je Frank Oltmanns napisal(a): > > On 2023-12-19 at 17:54:19 +0100, Jernej Škrabec > wrote: > > Dne ponedeljek, 18. december 2023 ob 14:35:22 CET je Frank Oltmanns > > napisal(a): > >> The Allwinner A64 manual lists the following constraint for the > >> PLL-VIDEO0 clock: 8 <= N/M <= 25 > >> > >> Use this constraint. > >> > >> Signed-off-by: Frank Oltmanns > >> --- > >> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 8 ++-- > >> 1 file changed, 6 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c > >> b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c > >> index c034ac027d1c..75d839da446c 100644 > >> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c > >> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c > >> @@ -68,7 +68,8 @@ static > >> SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, "pll-audio-base", > >> BIT(28), /* lock */ > >> CLK_SET_RATE_UNGATE); > >> > >> -static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, > >> "pll-video0", > >> +static > >> SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_FEAT_NM_RATIO(pll_video0_clk, > >> + "pll-video0", > >>"osc24M", 0x010, > >>19200, /* Minimum rate > >> */ > >>100800, /* Maximum rate > >> */ > > I just realized that adding the whole ratio limits for ccu_nm is > superfluous as you could just as well express them in for of a minimum > and maximum range: > Since 8 <= N/M <= 25 and parent_rate = 24 MHz, therefore > 192 MHz <= rate <= 600 MHz. Good point! > > These absolute limits are also listed in Allwinner's A64 manual. > > BUT, here the upper limit was raised to 1008 MHz: > 5de39acaf34604bd04834f092479cf4dcc946dd "clk: sunxi-ng: a64: Add max. > rate constraint to video PLL" > > With this upper limit the ratio limitation is effectively: > 8 <= N/M <= 42 > > Icenowy Zheng (added to CC) had the reasonable explanation that this was > used in the BSP kernel, so we should probably stick to that and ditch > the two PLL-VIDEO0 related patches. What are your thoughts on that? Ok, it seems that these patches are really superfluous. Remove them for v2. Best regards, Jernej > > >> @@ -80,7 +81,10 @@ static > >> SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN_MAX_CLOSEST(pll_video0_clk, "pll-vid > >>29700, /* frac rate 1 > >> */ > >>BIT(31),/* gate */ > >>BIT(28),/* lock */ > >> - CLK_SET_RATE_UNGATE); > >> + CLK_SET_RATE_UNGATE, > >> + CCU_FEATURE_FRACTIONAL | > >> + CCU_FEATURE_CLOSEST_RATE, > > > > Above flags are unrelated change, put them in new patch if needed. > > > > Best regards, > > Jernej > > > >> + 8, 25); /* min/max nm > >> ratio */ > >> > >> static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve", > >>"osc24M", 0x018, > >> > >> >
Re: [PATCH 02/11] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
On 09/01/2024 18:19, Andrew Davis wrote: > The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from > multiple vendors. Describe how the SGX GPU is integrated in these SoC, > including register space and interrupts. Clocks, reset, and power domain > information is SoC specific. > > Signed-off-by: Andrew Davis > Reviewed-by: Javier Martinez Canillas > + clock-names: > +minItems: 1 > +items: > + - const: core > + - const: mem > + - const: sys There are no devices currently using third clock, but I assume it is expected or possible. Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
On 09/01/2024 18:19, Andrew Davis wrote: > This binding will be used for GPUs starting from Series6 (Rogue) > and later. A different binding document will describe Series5. > With that the name "img,powervr" is too generic, rename to > "img,powervr-rogue" to avoid confusion. > > Suggested-by: Maxime Ripard > Signed-off-by: Andrew Davis > Reviewed-by: Javier Martinez Canillas > Reviewed-by: Frank Binns Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
On 09/01/2024 20:33, Andrew Davis wrote: > On 1/9/24 1:17 PM, Krzysztof Kozlowski wrote: >> On 09/01/2024 20:04, Andrew Davis wrote: >>> On 1/9/24 12:59 PM, Krzysztof Kozlowski wrote: On 09/01/2024 18:19, Andrew Davis wrote: > This binding will be used for GPUs starting from Series6 (Rogue) > and later. A different binding document will describe Series5. > With that the name "img,powervr" is too generic, rename to > "img,powervr-rogue" to avoid confusion. > > Suggested-by: Maxime Ripard > Signed-off-by: Andrew Davis > Reviewed-by: Javier Martinez Canillas > Reviewed-by: Frank Binns > --- Why do you send new version while we still talk about previous? Please implement feedback from v1 (and this is v2, so next is v3) or keep discussing. >>> >>> I agreed with everything you said in the last round (RFC v2) and >>> made all requested changes. Did I miss something in this version? >> >> The recommendation is that naming of the file matches generic compatible >> and your file has only one generic compatible. Therefore I don't >> understand why you claimed there are multiple compatibles. >> > > I said "There are (or will be) multiple compatible strings", the rest OK. > are on the way. So I didn't want to make this file less generic when > other bindings are almost ready. > > Frank, can you help here, I'm assuming you have "img,img-bxs" and > "img,img-8xe" bindings staged for upstreaming somewhere; you'll be > putting those in this same file, right? > That's fine then. Best regards, Krzysztof
Re: [PATCH 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
On 1/9/24 1:17 PM, Krzysztof Kozlowski wrote: On 09/01/2024 20:04, Andrew Davis wrote: On 1/9/24 12:59 PM, Krzysztof Kozlowski wrote: On 09/01/2024 18:19, Andrew Davis wrote: This binding will be used for GPUs starting from Series6 (Rogue) and later. A different binding document will describe Series5. With that the name "img,powervr" is too generic, rename to "img,powervr-rogue" to avoid confusion. Suggested-by: Maxime Ripard Signed-off-by: Andrew Davis Reviewed-by: Javier Martinez Canillas Reviewed-by: Frank Binns --- Why do you send new version while we still talk about previous? Please implement feedback from v1 (and this is v2, so next is v3) or keep discussing. I agreed with everything you said in the last round (RFC v2) and made all requested changes. Did I miss something in this version? The recommendation is that naming of the file matches generic compatible and your file has only one generic compatible. Therefore I don't understand why you claimed there are multiple compatibles. I said "There are (or will be) multiple compatible strings", the rest are on the way. So I didn't want to make this file less generic when other bindings are almost ready. Frank, can you help here, I'm assuming you have "img,img-bxs" and "img,img-8xe" bindings staged for upstreaming somewhere; you'll be putting those in this same file, right? Thanks, Andrew Best regards, Krzysztof
Re: [PATCH v3 3/4] drm/msm: add a kernel param to select between MDP5 and DPU drivers
On 1/8/2024 11:07 AM, Dmitry Baryshkov wrote:
On Mon, 8 Jan 2024 at 19:57, Carl Vanderlip wrote:
On 1/5/2024 4:38 PM, Dmitry Baryshkov wrote:
On Sat, 6 Jan 2024 at 02:04, Carl Vanderlip wrote:
On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 50b65ffc24b1..ef57586fbeca 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -969,6 +969,37 @@ static int add_components_mdp(struct device *master_dev,
return 0;
}
+#if !IS_REACHABLE(CONFIG_DRM_MSM_MDP5) || !IS_REACHABLE(CONFIG_DRM_MSM_DPU)
+bool msm_disp_drv_should_bind(struct device *dev, bool mdp5_driver)
+{
+ /* If just a single driver is enabled, use it no matter what */
+ return true;
+}
This will cause both MDP/DPU probes to return -ENODEV, rather than
select the enabled one.
No. The code (e.g. for DPU) is:
if (!msm_disp_drv_should_bind(>dev, true))
return -ENODEV;
So the driver returns -ENODEV if msm_disp_drv_should_bind() returns
false. Which is logical from the function name point of view.
but msm_disp_drv_should_bind() is returning true in the #if !REACHABLE()
case?
at minimum the comment is incorrect since returning true causes the
driver to NOT be used.
No. Returning _false_ causes the driver to not be used.
Apologies... you are correct.
Reviewed-by: Carl Vanderlip
-Carl V.
Re: [PATCH 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
On 09/01/2024 20:04, Andrew Davis wrote: > On 1/9/24 12:59 PM, Krzysztof Kozlowski wrote: >> On 09/01/2024 18:19, Andrew Davis wrote: >>> This binding will be used for GPUs starting from Series6 (Rogue) >>> and later. A different binding document will describe Series5. >>> With that the name "img,powervr" is too generic, rename to >>> "img,powervr-rogue" to avoid confusion. >>> >>> Suggested-by: Maxime Ripard >>> Signed-off-by: Andrew Davis >>> Reviewed-by: Javier Martinez Canillas >>> Reviewed-by: Frank Binns >>> --- >> >> Why do you send new version while we still talk about previous? >> >> Please implement feedback from v1 (and this is v2, so next is v3) or >> keep discussing. >> > > I agreed with everything you said in the last round (RFC v2) and > made all requested changes. Did I miss something in this version? The recommendation is that naming of the file matches generic compatible and your file has only one generic compatible. Therefore I don't understand why you claimed there are multiple compatibles. Best regards, Krzysztof
Re: [PATCH 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
On 1/9/24 12:59 PM, Krzysztof Kozlowski wrote: On 09/01/2024 18:19, Andrew Davis wrote: This binding will be used for GPUs starting from Series6 (Rogue) and later. A different binding document will describe Series5. With that the name "img,powervr" is too generic, rename to "img,powervr-rogue" to avoid confusion. Suggested-by: Maxime Ripard Signed-off-by: Andrew Davis Reviewed-by: Javier Martinez Canillas Reviewed-by: Frank Binns --- Why do you send new version while we still talk about previous? Please implement feedback from v1 (and this is v2, so next is v3) or keep discussing. I agreed with everything you said in the last round (RFC v2) and made all requested changes. Did I miss something in this version? Thanks, Andrew Best regards, Krzysztof
Re: [PATCH 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
On 09/01/2024 18:19, Andrew Davis wrote: > This binding will be used for GPUs starting from Series6 (Rogue) > and later. A different binding document will describe Series5. > With that the name "img,powervr" is too generic, rename to > "img,powervr-rogue" to avoid confusion. > > Suggested-by: Maxime Ripard > Signed-off-by: Andrew Davis > Reviewed-by: Javier Martinez Canillas > Reviewed-by: Frank Binns > --- Why do you send new version while we still talk about previous? Please implement feedback from v1 (and this is v2, so next is v3) or keep discussing. Best regards, Krzysztof
Re: [PATCH RFC v2 02/11] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
On 09/01/2024 17:53, Andrew Davis wrote:
> On 1/9/24 5:32 AM, Krzysztof Kozlowski wrote:
>> On 08/01/2024 19:32, Andrew Davis wrote:
>>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
>>> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
>>> including register space and interrupts. Clocks, reset, and power domain
>>> information is SoC specific.
>>>
>>> Signed-off-by: Andrew Davis
>>> ---
>>> .../bindings/gpu/img,powervr-sgx.yaml | 124 ++
>>> MAINTAINERS | 1 +
>>> 2 files changed, 125 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
>>> b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
>>> new file mode 100644
>>> index 0..bb821e1184de9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
>>> @@ -0,0 +1,124 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +# Copyright (c) 2023 Imagination Technologies Ltd.
>>
>> Your email has @TI domain, are you sure you attribute your copyrights to
>> Imagination?
>>
>
> The file started as a copy/paste from a IMG copyrighted file, even
> though it is now almost completely re-written I've left their (c)
> for good measure. I'll add an additional TI (c).
>
>> ...
>>
>>> +
>>> + reg:
>>> +maxItems: 1
>>> +
>>> + interrupts:
>>> +maxItems: 1
>>> +
>>> + clocks: true
>>
>> Missing min/maxItems
>>
>
> These are set in the allOf/if/then blocks below, seems
I know, but we expect them here.
https://elixir.bootlin.com/linux/v5.19-rc6/source/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml#L57
> if I don't set them to at least something here then I get
> a warning:
>
> 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
>
> even if I define them in the allOf block below. I don't
> know what the min/max should be until I check the compatible
> in the allOf block.
As always: the widest constraints.
...
> Logic in YAML always seems messy to me, here it is in pseudo C:
>
> if (compatible == allwinner,sun6i-a31-gpu ||
> compatible == ingenic,jz4780-gpu) {
> if (compatible == allwinner,sun6i-a31-gpu)
> clocks: ...
> if (compatible == ingenic,jz4780-gpu)
> clocks: ...
> required:
> - clocks
> - clock-names
> } else { /* disallow for all others */
> properties:
> clocks: false
> clock-names: false
> }
OK, I see, that's the limitation of YAML. The point is that this code is
not readable, so just list all fallbacks or variants.
Best regards,
Krzysztof
Re: [PATCH RFC v2 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
On 09/01/2024 17:14, Andrew Davis wrote:
> On 1/9/24 5:28 AM, Krzysztof Kozlowski wrote:
>> On 08/01/2024 19:32, Andrew Davis wrote:
>>> Signed-off-by: Andrew Davis
>>> ---
>>> .../bindings/gpu/{img,powervr.yaml => img,powervr-rogue.yaml} | 4 ++--
>>> MAINTAINERS | 2 +-
>>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>
>> If you are renaming it, why not renaming to match compatible as we
>> usually expect?
>>
>
> There are (or will be) multiple compatible strings described in this
> file, naming the file after just one would not fully convey the content
> of the file. This generic style naming seems common already for bindings
> with multiple compatibles.
I saw only one compatible used as fallback. Where are more?
Best regards,
Krzysztof
Re: [DO NOT MERGE v6 04/37] dt-bindings: interrupt-controller: Add header for Renesas SH3/4 INTC.
On 09/01/2024 09:23, Yoshinori Sato wrote: > Renesas SH7751 Interrupt controller priority register define. > Still not a binding. Some parts of my comments are implemented, others are just ignored (dropping the file, fixing full stop in commit msg). This is confusing. I don't know. Shall I just NAK it to make it clear? NAK Best regards, Krzysztof
Re: [PATCH v2 2/2] gpu: drm: panel: panel-simple: add new display mode for waveshare 7inch touchscreen panel
On 1/8/2024 11:09 PM, Shengyang Chen wrote:
The waveshare 7" 800x480 panel is a clone of Raspberry Pi 7" 800x480 panel
It also uses a Toshiba TC358762 DSI to DPI bridge chip but it needs different
timing from Raspberry Pi panel. Add new timing for it.
Hi Shengyang,
The patch itself LGTM, but in case you have to put out a new revision,
can you please use the "drm/panel: :" prefix format that
other drm/panel commits use?
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
Signed-off-by: Keith Zhao
Signed-off-by: Shengyang Chen
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9367a4572dcf..e0896873ea33 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4110,6 +4110,31 @@ static const struct panel_desc vl050_8048nt_c01 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
};
+static const struct drm_display_mode waveshare_7inch_mode = {
+ .clock = 2970 / 1000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 90,
+ .hsync_end = 800 + 90 + 5,
+ .htotal = 800 + 90 + 5 + 5,
+ .vdisplay = 480,
+ .vsync_start = 480 + 60,
+ .vsync_end = 480 + 60 + 5,
+ .vtotal = 480 + 60 + 5 + 5,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc waveshare_7inch = {
+ .modes = _7inch_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .connector_type = DRM_MODE_CONNECTOR_DSI,
+};
+
static const struct drm_display_mode winstar_wf35ltiacd_mode = {
.clock = 6410,
.hdisplay = 320,
@@ -4592,6 +4617,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "vxt,vl050-8048nt-c01",
.data = _8048nt_c01,
+ }, {
+ .compatible = "waveshare,7inch-touchscreen",
+ .data = _7inch,
}, {
.compatible = "winstar,wf35ltiacd",
.data = _wf35ltiacd,
--
2.17.1
[PATCH] Revert "drm/msm/gpu: Push gpu lock down past runpm"
From: Rob Clark
This reverts commit abe2023b4cea192ab266b351fd38dc9dbd846df0.
Changing the locking order means that scheduler/msm_job_run() can race
with the recovery kthread worker, with the result that the GPU gets an
extra runpm get when we are trying to power it off. Leaving the GPU in
an unrecovered state.
I'll need to come up with a different scheme for appeasing lockdep.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c| 11 +--
drivers/gpu/drm/msm/msm_ringbuffer.c | 7 +--
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 095390774f22..655002b21b0d 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -751,12 +751,14 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
struct msm_ringbuffer *ring = submit->ring;
unsigned long flags;
- pm_runtime_get_sync(>pdev->dev);
+ WARN_ON(!mutex_is_locked(>lock));
- mutex_lock(>lock);
+ pm_runtime_get_sync(>pdev->dev);
msm_gpu_hw_init(gpu);
+ submit->seqno = submit->hw_fence->seqno;
+
update_sw_cntrs(gpu);
/*
@@ -781,11 +783,8 @@ void msm_gpu_submit(struct msm_gpu *gpu, struct
msm_gem_submit *submit)
gpu->funcs->submit(gpu, submit);
gpu->cur_ctx_seqno = submit->queue->ctx->seqno;
- hangcheck_timer_reset(gpu);
-
- mutex_unlock(>lock);
-
pm_runtime_put(>pdev->dev);
+ hangcheck_timer_reset(gpu);
}
/*
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index e0ed27739449..548f5266a7d3 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -21,8 +21,6 @@ static struct dma_fence *msm_job_run(struct drm_sched_job
*job)
msm_fence_init(submit->hw_fence, fctx);
- submit->seqno = submit->hw_fence->seqno;
-
mutex_lock(>lru.lock);
for (i = 0; i < submit->nr_bos; i++) {
@@ -35,8 +33,13 @@ static struct dma_fence *msm_job_run(struct drm_sched_job
*job)
mutex_unlock(>lru.lock);
+ /* TODO move submit path over to using a per-ring lock.. */
+ mutex_lock(>lock);
+
msm_gpu_submit(gpu, submit);
+ mutex_unlock(>lock);
+
return dma_fence_get(submit->hw_fence);
}
--
2.43.0
Re: [DO NOT MERGE v6 27/37] dt-bindings: ata: ata-generic: Add new targets
On Tue, Jan 09, 2024 at 06:07:19PM +, Conor Dooley wrote: > On Tue, Jan 09, 2024 at 05:23:24PM +0900, Yoshinori Sato wrote: > > Added new ata-generic target. > > - iodata,usl-5p-ata > > - renesas,rts7751r2d-ata > > > > Each boards have simple IDE Interface. Use ATA generic driver. > > > > Signed-off-by: Yoshinori Sato > > Acked-by: Conor Dooley That said, a bullet point list in the commit message of what compatibles you added isn't really achieving anything, you can drop that from the commit message if/when you resend the series. > > Cheers, > Conor. > > > --- > > Documentation/devicetree/bindings/ata/ata-generic.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/ata/ata-generic.yaml > > b/Documentation/devicetree/bindings/ata/ata-generic.yaml > > index 0697927f3d7e..1025b3b351d0 100644 > > --- a/Documentation/devicetree/bindings/ata/ata-generic.yaml > > +++ b/Documentation/devicetree/bindings/ata/ata-generic.yaml > > @@ -18,6 +18,8 @@ properties: > >- enum: > >- arm,vexpress-cf > >- fsl,mpc8349emitx-pata > > + - iodata,usl-5p-ata > > + - renesas,rts7751r2d-ata > >- const: ata-generic > > > >reg: > > -- > > 2.39.2 > > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 27/37] dt-bindings: ata: ata-generic: Add new targets
On Tue, Jan 09, 2024 at 05:23:24PM +0900, Yoshinori Sato wrote: > Added new ata-generic target. > - iodata,usl-5p-ata > - renesas,rts7751r2d-ata > > Each boards have simple IDE Interface. Use ATA generic driver. > > Signed-off-by: Yoshinori Sato Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/ata/ata-generic.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/ata/ata-generic.yaml > b/Documentation/devicetree/bindings/ata/ata-generic.yaml > index 0697927f3d7e..1025b3b351d0 100644 > --- a/Documentation/devicetree/bindings/ata/ata-generic.yaml > +++ b/Documentation/devicetree/bindings/ata/ata-generic.yaml > @@ -18,6 +18,8 @@ properties: >- enum: >- arm,vexpress-cf >- fsl,mpc8349emitx-pata > + - iodata,usl-5p-ata > + - renesas,rts7751r2d-ata >- const: ata-generic > >reg: > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 26/37] dt-bindings: vendor-prefixes: Add smi
On Tue, Jan 09, 2024 at 05:23:23PM +0900, Yoshinori Sato wrote: > Add Silicon Mortion Technology Corporation > https://www.siliconmotion.com/ > > Signed-off-by: Yoshinori Sato > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 94ed63d9f7de..a338bdd743ab 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -1283,6 +1283,8 @@ patternProperties: > description: Skyworks Solutions, Inc. >"^smartlabs,.*": > description: SmartLabs LLC > + "^smi,.*": > +description: Silicon Motion Technology Corporation How come "smi" is used for a company with this name? Why is it not something like SMTC? There's probably some history here that I am unaware of. Cheers, Conor. >"^smsc,.*": > description: Standard Microsystems Corporation >"^snps,.*": > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 25/37] dt-bindings: vendor-prefixes: Add iodata
On Tue, Jan 09, 2024 at 05:23:22PM +0900, Yoshinori Sato wrote: > Add IO DATA DEVICE INC. > https://www.iodata.com/ > > Signed-off-by: Yoshinori Sato I think you are missing an r-b tag here from Geert: https://lore.kernel.org/all/camuhmduvnt1tdtoq4ppqn69cocaeveaxrsol2vq2efbq+hv...@mail.gmail.com/ Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml > b/Documentation/devicetree/bindings/vendor-prefixes.yaml > index 309b94c328c8..94ed63d9f7de 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml > +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml > @@ -671,6 +671,8 @@ patternProperties: > description: Inventec >"^inversepath,.*": > description: Inverse Path > + "^iodata,.*": > +description: IO DATA DEVICE Inc. >"^iom,.*": > description: Iomega Corporation >"^irondevice,.*": > -- > 2.39.2 > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 24/37] dt-binding: sh: cpus: Add SH CPUs json-schema
Yo,
On Tue, Jan 09, 2024 at 05:23:21PM +0900, Yoshinori Sato wrote:
> Renesas SH series and compatible ISA CPUs.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../devicetree/bindings/sh/cpus.yaml | 74 +++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sh/cpus.yaml
>
> diff --git a/Documentation/devicetree/bindings/sh/cpus.yaml
> b/Documentation/devicetree/bindings/sh/cpus.yaml
> new file mode 100644
> index ..c04f897d2c2a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sh/cpus.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sh/cpus.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SuperH CPUs
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description: |+
> + The device tree allows to describe the layout of CPUs in a system through
> + the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
> + defining properties for every cpu.
> +
> + Bindings for CPU nodes follow the Devicetree Specification, available from:
> +
> + https://www.devicetree.org/specifications/
You likely copied this description from the arm binding (or from
dt-schema), but I don't think this is anything other than a statement of
the obvious. If there is a description here it should (IMO) talk about
the superh cpus.
> +
> +properties:
> + compatible:
> +anyOf:
> + - items:
> + - enum:
> + - renesas,sh2a
> + - renesas,sh3
> + - renesas,sh4
> + - renesas,sh4a
> + - jcore,j2
> + - const: renesas,sh2
> + - const: renesas,sh2
> +
> + clock-frequency:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: CPU core clock frequency.
What is the point of this? You have a clocks property, can't you obtain
the clock frequency by looking up the provider of that clock?
> +
> + clocks:
> +maxItems: 1
> +
> + clock-names: true
Why do you need clock-names if you only have one clock?
> +
> + reg:
> +maxItems: 1
> +
> + device_type: true
> +
> +required:
> + - compatible
> + - reg
> + - device_type
> +
> +additionalProperties: true
This should be unevaluatedProperties: false
Properties like the icache-size are documented in cpu.yaml and
you can add an reference to that to permit them. The riscv cpus binding
does this if you need to see how that works.
Cheers,
Conor.
> +examples:
> + - |
> +#include
> +cpus {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +cpu: cpu@0 {
> +compatible = "renesas,sh4", "renesas,sh2";
> +device_type = "cpu";
> +reg = <0>;
> +clocks = < SH7750_CPG_ICK>;
> +clock-names = "ick";
> +icache-size = <16384>;
> +icache-line-size = <32>;
> +dcache-size = <32768>;
> +dcache-line-size = <32>;
> +};
> +};
> +...
> --
> 2.39.2
>
signature.asc
Description: PGP signature
Re: [DO NOT MERGE v6 12/37] dt-bindings: pci: pci-sh7751: Add SH7751 PCI
On Tue, Jan 09, 2024 at 01:42:53PM +0100, Linus Walleij wrote: > Hi Yoshinori, > > thanks for your patch! > > On Tue, Jan 9, 2024 at 9:24 AM Yoshinori Sato > wrote: > > > Renesas SH7751 PCI Controller json-schema. > > > > Signed-off-by: Yoshinori Sato > (...) > > + renesas,bus-arbit-round-robin: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set DMA bus arbitration to round robin. > > + > > + pci-command-reg-fast-back-to-back: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI command register Fast Back-to-Back enable bit. > > + > > + pci-command-reg-serr: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI command register SERR# enable. > > + > > + pci-command-reg-wait-cycle-control: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI command register Wait cycle control bit. > > + > > + pci-command-reg-parity-error-response: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI Command register Parity error response bit. > > + > > + pci-command-reg-vga-snoop: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI Command register VGA palette snoop bit. > > + > > + pci-command-reg-write-invalidate: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI Command register Memory write and invaldate enable bit. > > + > > + pci-command-reg-special-cycle: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI Command register Special cycle bit. > > + > > + pci-command-reg-bus-master: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI Command register Bus master bit. > > + > > + pci-command-reg-memory-space: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI Command register Memory space bit. > > + > > + pci-command-reg-io-space: > > +$ref: /schemas/types.yaml#/definitions/flag > > +description: | > > + Set for PCI Command register I/O space bit. > > Do you really need to configure all these things? It seems they are > just set to default values anyway? > > Can't you just look at the compatible "renesas,sh7751-pci" and > set it to the values you know are needed for that compatible? Yes. Please drop all these. > > > + pci-bar: > > +$ref: /schemas/types.yaml#/definitions/uint32-matrix > > +description: Overwrite to PCI CONFIG Base Address Registers value. > > +items: > > + items: > > +- description: BAR register number > > +- description: BAR register value > > +minItems: 1 > > +maxItems: 6 > > Same with this, isn't this always the same (hardcoded) values > for "renesas,sh7751-pci" if used? The OpenFirmware PCI bus supplement already defines how to specify BAR values in DT in "reg" or "assigned-addresses". If you need to specify these, use that. Note don't expect the kernel to do anything with them. Rob > > > +interrupt-map = <0x 0 0 1 5>, > > +<0x 0 0 2 6>, > > +<0x 0 0 3 7>, > > +<0x 0 0 4 8>, > > +<0x0800 0 0 1 6>, > > +<0x0800 0 0 2 7>, > > +<0x0800 0 0 3 8>, > > +<0x0800 0 0 4 5>, > > +<0x1000 0 0 1 7>, > > +<0x1000 0 0 2 8>, > > +<0x1000 0 0 3 5>, > > +<0x1000 0 0 4 6>; > > This interrupt-map looks very strange, usually the last cell is the polarity > flag and here it is omitted? I would expect something like: > > <0x 0 0 1 5 IRQ_TYPE_LEVEL_LOW>, (...) > > The interrupt-map schema in dtschema isn't really looking at this > so it is easy to get it wrong. dtc should IIRC. Maybe not in the example being incomplete. Rob
Re: [PATCH] drm/v3d: Fix support for register debugging on the RPi 4
On 1/9/24 09:07, Iago Toral wrote:
Thanks Maíra!
Reviewed-by: Iago Toral Quiroga
Applied to drm-misc/drm-misc-next-fixes!
Best Regards,
- Maíra
El mar, 09-01-2024 a las 08:30 -0300, Maíra Canal escribió:
RPi 4 uses V3D 4.2, which is currently not supported by the register
definition stated at `v3d_core_reg_defs`. We should be able to
support
V3D 4.2, therefore, change the maximum version of the register
definition to 42, not 41.
Fixes: 0ad5bc1ce463 ("drm/v3d: fix up register addresses for V3D
7.x")
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index f843a50d5dce..94eafcecc65b 100644
--- a/drivers/gpu/drm/v3d/v3d_debugfs.c
+++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
@@ -62,9 +62,9 @@ static const struct v3d_reg_def v3d_core_reg_defs[]
= {
REGDEF(33, 71, V3D_PTB_BPCA),
REGDEF(33, 71, V3D_PTB_BPCS),
- REGDEF(33, 41, V3D_GMP_STATUS(33)),
- REGDEF(33, 41, V3D_GMP_CFG(33)),
- REGDEF(33, 41, V3D_GMP_VIO_ADDR(33)),
+ REGDEF(33, 42, V3D_GMP_STATUS(33)),
+ REGDEF(33, 42, V3D_GMP_CFG(33)),
+ REGDEF(33, 42, V3D_GMP_VIO_ADDR(33)),
REGDEF(33, 71, V3D_ERR_FDBGO),
REGDEF(33, 71, V3D_ERR_FDBGB),
@@ -74,13 +74,13 @@ static const struct v3d_reg_def
v3d_core_reg_defs[] = {
static const struct v3d_reg_def v3d_csd_reg_defs[] = {
REGDEF(41, 71, V3D_CSD_STATUS),
- REGDEF(41, 41, V3D_CSD_CURRENT_CFG0(41)),
- REGDEF(41, 41, V3D_CSD_CURRENT_CFG1(41)),
- REGDEF(41, 41, V3D_CSD_CURRENT_CFG2(41)),
- REGDEF(41, 41, V3D_CSD_CURRENT_CFG3(41)),
- REGDEF(41, 41, V3D_CSD_CURRENT_CFG4(41)),
- REGDEF(41, 41, V3D_CSD_CURRENT_CFG5(41)),
- REGDEF(41, 41, V3D_CSD_CURRENT_CFG6(41)),
+ REGDEF(41, 42, V3D_CSD_CURRENT_CFG0(41)),
+ REGDEF(41, 42, V3D_CSD_CURRENT_CFG1(41)),
+ REGDEF(41, 42, V3D_CSD_CURRENT_CFG2(41)),
+ REGDEF(41, 42, V3D_CSD_CURRENT_CFG3(41)),
+ REGDEF(41, 42, V3D_CSD_CURRENT_CFG4(41)),
+ REGDEF(41, 42, V3D_CSD_CURRENT_CFG5(41)),
+ REGDEF(41, 42, V3D_CSD_CURRENT_CFG6(41)),
REGDEF(71, 71, V3D_CSD_CURRENT_CFG0(71)),
REGDEF(71, 71, V3D_CSD_CURRENT_CFG1(71)),
REGDEF(71, 71, V3D_CSD_CURRENT_CFG2(71)),
--
2.43.0
Re: [PATCH 3/5] drm/ttm: replace busy placement with flags v5
On Tue, Jan 9, 2024 at 2:47 AM Christian König
wrote:
>
> From: Somalapuram Amaranath
>
> Instead of a list of separate busy placement add flags which indicate
> that a placement should only be used when there is room or if we need to
> evict.
>
> v2: add missing TTM_PL_FLAG_IDLE for i915
> v3: fix auto build test ERROR on drm-tip/drm-tip
> v4: fix some typos pointed out by checkpatch
> v5: cleanup some rebase problems with VMWGFX
>
> Signed-off-by: Christian König
> Signed-off-by: Somalapuram Amaranath
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 11 +---
> drivers/gpu/drm/drm_gem_vram_helper.c | 2 -
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 37 +--
> drivers/gpu/drm/loongson/lsdc_ttm.c| 2 -
> drivers/gpu/drm/nouveau/nouveau_bo.c | 59 +++--
> drivers/gpu/drm/nouveau/nouveau_bo.h | 1 -
> drivers/gpu/drm/qxl/qxl_object.c | 2 -
> drivers/gpu/drm/qxl/qxl_ttm.c | 2 -
> drivers/gpu/drm/radeon/radeon_object.c | 2 -
> drivers/gpu/drm/radeon/radeon_ttm.c| 8 +--
> drivers/gpu/drm/radeon/radeon_uvd.c| 1 -
> drivers/gpu/drm/ttm/ttm_bo.c | 21 ---
> drivers/gpu/drm/ttm/ttm_resource.c | 73 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 2 -
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 4 --
> include/drm/ttm/ttm_placement.h| 10 +--
> include/drm/ttm/ttm_resource.h | 8 +--
> 18 files changed, 79 insertions(+), 172 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index cef920a93924..aa0dd6dad068 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -220,9 +220,6 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo
> *abo, u32 domain)
>
> placement->num_placement = c;
> placement->placement = places;
> -
> - placement->num_busy_placement = c;
> - placement->busy_placement = places;
> }
>
> /**
> @@ -1406,8 +1403,7 @@ vm_fault_t amdgpu_bo_fault_reserve_notify(struct
> ttm_buffer_object *bo)
> AMDGPU_GEM_DOMAIN_GTT);
>
> /* Avoid costly evictions; only set GTT as a busy placement */
> - abo->placement.num_busy_placement = 1;
> - abo->placement.busy_placement = >placements[1];
> + abo->placements[0].flags |= TTM_PL_FLAG_IDLE;
>
> r = ttm_bo_validate(bo, >placement, );
> if (unlikely(r == -EBUSY || r == -ERESTARTSYS))
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 05991c5c8ddb..9a6a00b1af40 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -102,23 +102,19 @@ static void amdgpu_evict_flags(struct ttm_buffer_object
> *bo,
> /* Don't handle scatter gather BOs */
> if (bo->type == ttm_bo_type_sg) {
> placement->num_placement = 0;
> - placement->num_busy_placement = 0;
> return;
> }
>
> /* Object isn't an AMDGPU object so ignore */
> if (!amdgpu_bo_is_amdgpu_bo(bo)) {
> placement->placement =
> - placement->busy_placement =
> placement->num_placement = 1;
> - placement->num_busy_placement = 1;
> return;
> }
>
> abo = ttm_to_amdgpu_bo(bo);
> if (abo->flags & AMDGPU_GEM_CREATE_DISCARDABLE) {
> placement->num_placement = 0;
> - placement->num_busy_placement = 0;
> return;
> }
>
> @@ -128,13 +124,13 @@ static void amdgpu_evict_flags(struct ttm_buffer_object
> *bo,
> case AMDGPU_PL_OA:
> case AMDGPU_PL_DOORBELL:
> placement->num_placement = 0;
> - placement->num_busy_placement = 0;
> return;
>
> case TTM_PL_VRAM:
> if (!adev->mman.buffer_funcs_enabled) {
> /* Move to system memory */
> amdgpu_bo_placement_from_domain(abo,
> AMDGPU_GEM_DOMAIN_CPU);
> +
> } else if (!amdgpu_gmc_vram_full_visible(>gmc) &&
>!(abo->flags &
> AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) &&
>amdgpu_bo_in_cpu_visible_vram(abo)) {
> @@ -149,8 +145,7 @@ static void amdgpu_evict_flags(struct ttm_buffer_object
> *bo,
>
> AMDGPU_GEM_DOMAIN_CPU);
> abo->placements[0].fpfn = adev->gmc.visible_vram_size
> >> PAGE_SHIFT;
> abo->placements[0].lpfn = 0;
> - abo->placement.busy_placement = >placements[1];
> - abo->placement.num_busy_placement = 1;
> +
Re: [PATCH v2 0/2] Add waveshare 7inch touchscreen panel support
Hi On Tue, 9 Jan 2024 at 11:19, wrote: > > Hi, > > On 09/01/2024 08:09, Shengyang Chen wrote: > > This patchset adds waveshare 7inch touchscreen panel support > > for the StarFive JH7110 SoC. > > Could you precise which SKU you're referring to ? is it 19885 => > https://www.waveshare.com/7inch-dsi-lcd.htm ? > > Are you sure it requires different timings from the RPi one ? In the Waveshare > wiki it explicitly uses the rpi setup (vc4-kms-dsi-7inch) to drive it: > https://www.waveshare.com/wiki/7inch_DSI_LCD I raise the same question. Keith Zhao earlier submitted effectively the same set of patches [1] and the response for the updated timing was: My platform dphy tx hardware has certain limitations. Only supports integer multiples of 10M bitrate: such as 160M ,170M, 180M,190M,...1G(max) as common dphy bitrate = pixclock*bpp/lanes. This value cannot match successfully in most cases. so in order to match bitrate , I choose a bitrate value around pixclock*bpp/lanes, Prevent overflow and underflow by fine-tuning the timing parameters:-( that will make the new timming value. I then suggested mode_fixup should be used in the DSI host driver, and Keith acknowledged that. Is this new timing still because of the DSI host requirement? Dave [1] https://lists.freedesktop.org/archives/dri-devel/2023-December/434150.html > Neil > > > > > > > changes since v1: > > - Rebased on tag v6.7. > > > > patch 1: > > - Gave up original changing. > > - Changed the commit message. > > - Add compatible in panel-simple.yaml > > > > patch 2: > > - Gave up original changing. > > - Changed the commit message. > > - Add new mode for the panel in panel-simple.c > > > > v1: > > https://patchwork.kernel.org/project/dri-devel/cover/20231124104451.44271-1-shengyang.c...@starfivetech.com/ > > > > Shengyang Chen (2): > >dt-bindings: display: panel: panel-simple: Add compatible property for > > waveshare 7inch touchscreen panel > >gpu: drm: panel: panel-simple: add new display mode for waveshare > > 7inch touchscreen panel > > > > .../bindings/display/panel/panel-simple.yaml | 2 ++ > > drivers/gpu/drm/panel/panel-simple.c | 28 +++ > > 2 files changed, 30 insertions(+) > > >
Re: [PATCH v2 0/2] Add waveshare 7inch touchscreen panel support
Hi Neil, Am 09.01.24 um 12:19 schrieb neil.armstr...@linaro.org: Hi, On 09/01/2024 08:09, Shengyang Chen wrote: This patchset adds waveshare 7inch touchscreen panel support for the StarFive JH7110 SoC. Could you precise which SKU you're referring to ? is it 19885 => https://www.waveshare.com/7inch-dsi-lcd.htm ? Are you sure it requires different timings from the RPi one ? In the Waveshare wiki it explicitly uses the rpi setup (vc4-kms-dsi-7inch) to drive it: https://www.waveshare.com/wiki/7inch_DSI_LCD i don't have an anser for your question, but the Raspberry Pi vendor tree use different timings than the Mainline kernel: https://github.com/raspberrypi/linux/commit/222b9baa97cc4c880d040a8c6a5da80d6a42c8e8 Additionally the arm64/boot/dts/freescale/imx8mm-venice-gw72xx-0x-rpidsi.dtso suggests that it uses the Raspberry Pi 7inch, but uses the timings of powertip,ph800480t013-idf02 from panel-simple. Maybe Shengyang could test these timings with the Waveshare touch. At the end this rely on a proper implementation on the underlying drivers. Sorry, for adding more confusion. Regards Neil changes since v1: - Rebased on tag v6.7. patch 1: - Gave up original changing. - Changed the commit message. - Add compatible in panel-simple.yaml patch 2: - Gave up original changing. - Changed the commit message. - Add new mode for the panel in panel-simple.c v1: https://patchwork.kernel.org/project/dri-devel/cover/20231124104451.44271-1-shengyang.c...@starfivetech.com/ Shengyang Chen (2): dt-bindings: display: panel: panel-simple: Add compatible property for waveshare 7inch touchscreen panel gpu: drm: panel: panel-simple: add new display mode for waveshare 7inch touchscreen panel .../bindings/display/panel/panel-simple.yaml | 2 ++ drivers/gpu/drm/panel/panel-simple.c | 28 +++ 2 files changed, 30 insertions(+)
[PATCH 02/11] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors. Describe how the SGX GPU is integrated in these SoC,
including register space and interrupts. Clocks, reset, and power domain
information is SoC specific.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
.../bindings/gpu/img,powervr-sgx.yaml | 138 ++
MAINTAINERS | 1 +
2 files changed, 139 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
new file mode 100644
index 0..f5898b04381cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 Imagination Technologies Ltd.
+# Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/img,powervr-sgx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination Technologies PowerVR SGX GPUs
+
+maintainers:
+ - Frank Binns
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - ti,omap3430-gpu # Rev 121
+ - ti,omap3630-gpu # Rev 125
+ - const: img,powervr-sgx530
+ - items:
+ - enum:
+ - ingenic,jz4780-gpu # Rev 130
+ - ti,omap4430-gpu # Rev 120
+ - const: img,powervr-sgx540
+ - items:
+ - enum:
+ - allwinner,sun6i-a31-gpu # MP2 Rev 115
+ - ti,omap4470-gpu # MP1 Rev 112
+ - ti,omap5432-gpu # MP2 Rev 105
+ - ti,am5728-gpu # MP2 Rev 116
+ - ti,am6548-gpu # MP1 Rev 117
+ - const: img,powervr-sgx544
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+minItems: 1
+maxItems: 3
+
+ clock-names:
+minItems: 1
+items:
+ - const: core
+ - const: mem
+ - const: sys
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,am6548-gpu
+then:
+ required:
+- power-domains
+else:
+ properties:
+power-domains: false
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - allwinner,sun6i-a31-gpu
+ - ingenic,jz4780-gpu
+then:
+ required:
+- clocks
+- clock-names
+else:
+ properties:
+clocks: false
+clock-names: false
+ - if:
+ properties:
+compatible:
+ contains:
+const: allwinner,sun6i-a31-gpu
+then:
+ properties:
+clocks:
+ minItems: 2
+ maxItems: 2
+clock-names:
+ minItems: 2
+ maxItems: 2
+ - if:
+ properties:
+compatible:
+ contains:
+const: ingenic,jz4780-gpu
+then:
+ properties:
+clocks:
+ maxItems: 1
+clock-names:
+ maxItems: 1
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+
+gpu@700 {
+compatible = "ti,am6548-gpu", "img,powervr-sgx544";
+reg = <0x700 0x1>;
+interrupts = ;
+power-domains = <_pds 65 TI_SCI_PD_EXCLUSIVE>;
+};
+
+ - |
+#include
+#include
+
+gpu: gpu@1c4 {
+compatible = "allwinner,sun6i-a31-gpu", "img,powervr-sgx544";
+reg = <0x01c4 0x1>;
+interrupts = ;
+clocks = < 1>, < 2>;
+clock-names = "core", "mem";
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 2a4e8d2c69c40..b8b3aab5dd490 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10469,6 +10469,7 @@ M: Matt Coster
S: Supported
T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
+F: Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
F: Documentation/gpu/imagination/
F: drivers/gpu/drm/imagination/
F: include/uapi/drm/pvr_drm.h
--
2.39.2
[PATCH 11/11] MIPS: DTS: jz4780: Add device tree entry for SGX GPU
Add SGX GPU device entry to base jz4780 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/mips/boot/dts/ingenic/jz4780.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 18a85ce38..5ea6833f5e872 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -460,6 +460,17 @@ hdmi: hdmi@1018 {
status = "disabled";
};
+ gpu: gpu@1304 {
+ compatible = "ingenic,jz4780-gpu", "img,powervr-sgx540";
+ reg = <0x1304 0x4000>;
+
+ clocks = < JZ4780_CLK_GPU>;
+ clock-names = "core";
+
+ interrupt-parent = <>;
+ interrupts = <63>;
+ };
+
lcdc0: lcdc0@1305 {
compatible = "ingenic,jz4780-lcd";
reg = <0x1305 0x1800>;
--
2.39.2
[PATCH 09/11] arm64: dts: ti: k3-am654-main: Add device tree entry for SGX GPU
Add SGX GPU device entry to base AM654 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index fcea544656360..64b52c8dafc6c 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -1050,6 +1050,13 @@ dss_ports: ports {
};
};
+ gpu: gpu@700 {
+ compatible = "ti,am6548-gpu", "img,powervr-sgx544";
+ reg = <0x0 0x700 0x0 0x1>;
+ interrupts = ;
+ power-domains = <_pds 65 TI_SCI_PD_EXCLUSIVE>;
+ };
+
ehrpwm0: pwm@300 {
compatible = "ti,am654-ehrpwm", "ti,am3352-ehrpwm";
#pwm-cells = <3>;
--
2.39.2
[PATCH 00/11] Device tree support for Imagination Series5 GPU
Hello all,
I know this has been tried before[0], but given the recent upstreaming of
the Series6+ GPU bindings I figured it might be time to give the Series5
bindings another try.
While there is currently no mainline driver for these binding, there is an
open source out-of-tree kernel-side driver available[1]. Having a stable
and upstream binding for these devices allows us to describe this hardware
in device tree.
This is my vision for how these bindings should look, along with some
example uses in several SoC DT files. The compatible names have been
updated to match what was decided on for Series6+, but otherwise most
is the same as we have been using in our vendor tree for many years.
Thanks,
Andrew
Based on next-20240109.
[0]: https://lkml.org/lkml/2020/4/24/1222
[1]: https://github.com/openpvrsgx-devgroup
Changes for v1:
- Added commit message to patch #1
- Reworked Rogue binding title
- Add TI copyright to new binding doc
- Added default min/maxItems to clocks property
- Moved "additionalProperties" to end
- Flattened out allOf block logic
- Added extra SGX binding example
- Added Suggested/Reviewed tags
Changes for RFC v2:
- Added patch to rename Rogue+ binding to img,powervr-rogue.yaml
- Locked all property item counts
- Removed nodename pattern check
Andrew Davis (11):
dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
ARM: dts: omap3: Add device tree entry for SGX GPU
ARM: dts: omap4: Add device tree entry for SGX GPU
ARM: dts: omap5: Add device tree entry for SGX GPU
ARM: dts: AM33xx: Add device tree entry for SGX GPU
ARM: dts: AM437x: Add device tree entry for SGX GPU
ARM: dts: DRA7xx: Add device tree entry for SGX GPU
arm64: dts: ti: k3-am654-main: Add device tree entry for SGX GPU
ARM: dts: sun6i: Add device tree entry for SGX GPU
MIPS: DTS: jz4780: Add device tree entry for SGX GPU
...mg,powervr.yaml => img,powervr-rogue.yaml} | 4 +-
.../bindings/gpu/img,powervr-sgx.yaml | 138 ++
MAINTAINERS | 3 +-
arch/arm/boot/dts/allwinner/sun6i-a31.dtsi| 9 ++
arch/arm/boot/dts/ti/omap/am33xx.dtsi | 9 +-
arch/arm/boot/dts/ti/omap/am3517.dtsi | 11 +-
arch/arm/boot/dts/ti/omap/am4372.dtsi | 6 +
arch/arm/boot/dts/ti/omap/dra7.dtsi | 9 +-
arch/arm/boot/dts/ti/omap/omap34xx.dtsi | 11 +-
arch/arm/boot/dts/ti/omap/omap36xx.dtsi | 9 +-
arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +-
arch/arm/boot/dts/ti/omap/omap5.dtsi | 9 +-
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 7 +
arch/mips/boot/dts/ingenic/jz4780.dtsi| 11 ++
14 files changed, 215 insertions(+), 30 deletions(-)
rename Documentation/devicetree/bindings/gpu/{img,powervr.yaml =>
img,powervr-rogue.yaml} (91%)
create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
--
2.39.2
[PATCH 01/11] dt-bindings: gpu: Rename img, powervr to img, powervr-rogue
This binding will be used for GPUs starting from Series6 (Rogue)
and later. A different binding document will describe Series5.
With that the name "img,powervr" is too generic, rename to
"img,powervr-rogue" to avoid confusion.
Suggested-by: Maxime Ripard
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Frank Binns
---
.../bindings/gpu/{img,powervr.yaml => img,powervr-rogue.yaml} | 4 ++--
MAINTAINERS | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
rename Documentation/devicetree/bindings/gpu/{img,powervr.yaml =>
img,powervr-rogue.yaml} (91%)
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
similarity index 91%
rename from Documentation/devicetree/bindings/gpu/img,powervr.yaml
rename to Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
index a13298f1a1827..256e252f8087f 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
@@ -2,10 +2,10 @@
# Copyright (c) 2023 Imagination Technologies Ltd.
%YAML 1.2
---
-$id: http://devicetree.org/schemas/gpu/img,powervr.yaml#
+$id: http://devicetree.org/schemas/gpu/img,powervr-rogue.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Imagination Technologies PowerVR and IMG GPU
+title: Imagination Technologies PowerVR and IMG Rogue GPUs
maintainers:
- Frank Binns
diff --git a/MAINTAINERS b/MAINTAINERS
index bcacd665f2594..2a4e8d2c69c40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10468,7 +10468,7 @@ M: Donald Robson
M: Matt Coster
S: Supported
T: git git://anongit.freedesktop.org/drm/drm-misc
-F: Documentation/devicetree/bindings/gpu/img,powervr.yaml
+F: Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
F: Documentation/gpu/imagination/
F: drivers/gpu/drm/imagination/
F: include/uapi/drm/pvr_drm.h
--
2.39.2
[PATCH 05/11] ARM: dts: omap5: Add device tree entry for SGX GPU
Add SGX GPU device entry to base OMAP5 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/omap5.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap5.dtsi
b/arch/arm/boot/dts/ti/omap/omap5.dtsi
index bac6fa8387936..6a66214ad0e2f 100644
--- a/arch/arm/boot/dts/ti/omap/omap5.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap5.dtsi
@@ -453,10 +453,11 @@ target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ gpu@0 {
+ compatible = "ti,omap5432-gpu",
"img,powervr-sgx544";
+ reg = <0x0 0x200>; /* 32MB */
+ interrupts = ;
+ };
};
target-module@5800 {
--
2.39.2
[PATCH 08/11] ARM: dts: DRA7xx: Add device tree entry for SGX GPU
Add SGX GPU device entry to base DRA7x dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/dra7.dtsi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ti/omap/dra7.dtsi
b/arch/arm/boot/dts/ti/omap/dra7.dtsi
index 6509c742fb58c..8527643cb69a8 100644
--- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
@@ -850,12 +850,19 @@ target-module@5600 {
;
ti,sysc-sidle = ,
,
- ;
+ ,
+ ;
clocks = <_clkctrl DRA7_GPU_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
+
+ gpu@0 {
+ compatible = "ti,am5728-gpu",
"img,powervr-sgx544";
+ reg = <0x0 0x1>; /* 64kB */
+ interrupts = ;
+ };
};
crossbar_mpu: crossbar@4a002a48 {
--
2.39.2
[PATCH 04/11] ARM: dts: omap4: Add device tree entry for SGX GPU
Add SGX GPU device entry to base OMAP4 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi
b/arch/arm/boot/dts/ti/omap/omap4.dtsi
index 2bbff9032be3e..559b2bfe4ca7c 100644
--- a/arch/arm/boot/dts/ti/omap/omap4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi
@@ -501,10 +501,11 @@ sgx_module: target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ gpu@0 {
+ compatible = "ti,omap4430-gpu",
"img,powervr-sgx540";
+ reg = <0x0 0x200>; /* 32MB */
+ interrupts = ;
+ };
};
/*
--
2.39.2
[PATCH 10/11] ARM: dts: sun6i: Add device tree entry for SGX GPU
Add SGX GPU device entry to base sun6i-a31 dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/allwinner/sun6i-a31.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
index 5cce4918f84c9..e6998783b89aa 100644
--- a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
@@ -962,6 +962,15 @@ mdio: mdio {
};
};
+ gpu: gpu@1c4 {
+ compatible = "allwinner,sun6i-a31-gpu",
"img,powervr-sgx544";
+ reg = <0x01c4 0x1>;
+ interrupts = ;
+ clocks = < CLK_GPU_CORE>, < CLK_GPU_MEMORY>;
+ clock-names = "core", "mem";
+ status = "disabled";
+ };
+
crypto: crypto-engine@1c15000 {
compatible = "allwinner,sun6i-a31-crypto",
"allwinner,sun4i-a10-crypto";
--
2.39.2
[PATCH 03/11] ARM: dts: omap3: Add device tree entry for SGX GPU
Add SGX GPU device entries to base OMAP3 dtsi files.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/am3517.dtsi | 11 ++-
arch/arm/boot/dts/ti/omap/omap34xx.dtsi | 11 ++-
arch/arm/boot/dts/ti/omap/omap36xx.dtsi | 9 +
3 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am3517.dtsi
b/arch/arm/boot/dts/ti/omap/am3517.dtsi
index 77e58e686fb17..19aad715dff70 100644
--- a/arch/arm/boot/dts/ti/omap/am3517.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am3517.dtsi
@@ -162,12 +162,13 @@ sgx_module: target-module@5000 {
clock-names = "fck", "ick";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0 0x5000 0x4000>;
+ ranges = <0 0x5000 0x1>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ gpu@0 {
+ compatible = "ti,omap3430-gpu",
"img,powervr-sgx530";
+ reg = <0x0 0x1>; /* 64kB */
+ interrupts = <21>;
+ };
};
};
};
diff --git a/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
b/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
index fc7233ac183a8..acdd0ee34421d 100644
--- a/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
@@ -164,12 +164,13 @@ sgx_module: target-module@5000 {
clock-names = "fck", "ick";
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0 0x5000 0x4000>;
+ ranges = <0 0x5000 0x1>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ gpu@0 {
+ compatible = "ti,omap3430-gpu",
"img,powervr-sgx530";
+ reg = <0x0 0x1>; /* 64kB */
+ interrupts = <21>;
+ };
};
};
diff --git a/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
b/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
index e6d8070c1bf88..c3d79ecd56e39 100644
--- a/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
@@ -211,10 +211,11 @@ sgx_module: target-module@5000 {
#size-cells = <1>;
ranges = <0 0x5000 0x200>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ gpu@0 {
+ compatible = "ti,omap3630-gpu",
"img,powervr-sgx530";
+ reg = <0x0 0x200>; /* 32MB */
+ interrupts = <21>;
+ };
};
};
--
2.39.2
[PATCH 06/11] ARM: dts: AM33xx: Add device tree entry for SGX GPU
Add SGX GPU device entry to base AM33xx dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/am33xx.dtsi | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
index 5b9e01a8aa5d5..989d5a6edeed9 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
@@ -640,10 +640,11 @@ target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x100>;
- /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+ gpu@0 {
+ compatible = "ti,omap3630-gpu",
"img,powervr-sgx530";
+ reg = <0x0 0x1>; /* 64kB */
+ interrupts = <37>;
+ };
};
};
};
--
2.39.2
[PATCH 07/11] ARM: dts: AM437x: Add device tree entry for SGX GPU
Add SGX GPU device entry to base AM437x dtsi file.
Signed-off-by: Andrew Davis
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/ti/omap/am4372.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/am4372.dtsi
b/arch/arm/boot/dts/ti/omap/am4372.dtsi
index 9d2c064534f7d..5fd1b380ece62 100644
--- a/arch/arm/boot/dts/ti/omap/am4372.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am4372.dtsi
@@ -719,6 +719,12 @@ target-module@5600 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x5600 0x100>;
+
+ gpu@0 {
+ compatible = "ti,omap3630-gpu",
"img,powervr-sgx530";
+ reg = <0x0 0x1>; /* 64kB */
+ interrupts = ;
+ };
};
};
};
--
2.39.2
Re: [DO NOT MERGE v6 19/37] dt-bindings: interrupt-controller: renesas,sh7751-irl-ext: Add json-schema
On Tue, Jan 09, 2024 at 05:23:16PM +0900, Yoshinori Sato wrote:
> Renesas SH7751 external interrupt encoder json-schema.
>
> Signed-off-by: Yoshinori Sato
> ---
> .../renesas,sh7751-irl-ext.yaml | 72 +++
> 1 file changed, 72 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
>
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
> new file mode 100644
> index ..541b582b94ce
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
> @@ -0,0 +1,72 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-irl-ext.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas SH7751 external interrupt encoder with enable regs.
> +
> +maintainers:
> + - Yoshinori Sato
> +
> +description:
> + This is the generally used external interrupt encoder on SH7751 based
> boards.
> +
> +properties:
> + compatible:
> +items:
> + - const: renesas,sh7751-irl-ext
> +
> + reg: true
Must define how many entries and what they are if more than one.
> +
> + interrupt-controller: true
> +
> + '#interrupt-cells':
> +const: 1
> +
> + '#address-cells':
> +const: 0
> +
> + renesas,set-to-disable:
> +$ref: /schemas/types.yaml#/definitions/flag
> +description: Invert enable registers. Setting the bit to 0 enables
> interrupts.
Why is this a property? Does it change per board or instance? If not, it
should be implied by compatible.
> +
> + renesas,enable-bit:
> +$ref: /schemas/types.yaml#/definitions/uint32-matrix
> +description: |
> + IRQ enable register bit mapping
> + 1st word interrupt level
> + 2nd word bit index of enable register
Same question here.
If it remains, then you need:
items:
items:
- description: interrupt level (does that mean high/low?)
- description: bit index of enable register
Plus any constraints on the values if possible.
> +
> +required:
> + - compatible
> + - reg
> + - interrupt-controller
> + - '#interrupt-cells'
> + - renesas,enable-bit
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +r2dintc: sh7751irl_encoder@a400 {
interrupt-controller@a400 {
> +compatible = "renesas,sh7751-irl-ext";
> +reg = <0xa400 0x02>;
> +interrupt-controller;
> +#address-cells = <0>;
> +#size-cells = <0>;
> +#interrupt-cells = <1>;
> +renesas,enable-bit = <0 11>,/* PCI INTD */
> + <1 9>, /* CF IDE */
> + <2 8>, /* CF CD */
> + <3 12>,/* PCI INTC */
> + <4 10>,/* SM501 */
> + <5 6>, /* KEY */
> + <6 5>, /* RTC ALARM */
> + <7 4>, /* RTC T */
> + <8 7>, /* SDCARD */
> + <9 14>,/* PCI INTA */
> + <10 13>, /* PCI INTB */
> + <11 0>,/* EXT */
> + <12 15>; /* TP */
Looks like 'interrupt level' is just the index of the values? Why not
make this an array?
Rob
Re: [PATCH RESEND] drm/bridge: Fixed a DP link training bug
On Thu, 21 Dec 2023 17:30:57 +0800, xiazhengqiao wrote: > To have better compatibility for DP sink, there is a retry mechanism > for the link training process to switch between different training process. > The original driver code doesn't reset the retry counter when training > state is pass. If the system triggers link training over 3 times, > there will be a chance to causes the driver to use the wrong training > method and return a training fail result. > > [...] Applied, thanks! [1/1] drm/bridge: Fixed a DP link training bug https://cgit.freedesktop.org/drm/drm-misc/commit/?id=ca077ff8cac5 Rob
Re: [PATCH] drm/ci: Add msm tests
On 1/9/2024 7:31 AM, Rob Clark wrote: On Mon, Jan 8, 2024 at 6:13 PM Rob Clark wrote: On Mon, Jan 8, 2024 at 2:58 PM Abhinav Kumar wrote: On 1/8/2024 11:50 AM, Rob Clark wrote: From: Rob Clark The msm tests should skip on non-msm hw, so I think it should be safe to enable everywhere. Signed-off-by: Rob Clark --- drivers/gpu/drm/ci/testlist.txt | 49 + 1 file changed, 49 insertions(+) I do see that all these tests use igt_msm_dev_open() to make sure it opens only the MSM card. But if igt_msm_dev_open() fails, I dont see a igt_require() on some of the tests to skip them. So how will it safely skip on non-msm HW? Unless i am missing something here hmm, at the time I added the initial msm tests, and igt_msm_dev_open(), I verified that they skipped on intel.. but since then I'd switched from intel to sc8280xp device for primary dev device, so I'd need to re-test to remember how it works. If these aren't skipping on !msm, it is a bug I double checked, these tests skip in drm_open_driver() with "No known gpu found for chipset flags 0x64 (msm)", so no problem to run them on all CI runners. BR, -R Ack, thanks for checking Reviewed-by: Abhinav Kumar BR, -R diff --git a/drivers/gpu/drm/ci/testlist.txt b/drivers/gpu/drm/ci/testlist.txt index f82cd90372f4..eaeb751bb0ad 100644 --- a/drivers/gpu/drm/ci/testlist.txt +++ b/drivers/gpu/drm/ci/testlist.txt @@ -2910,3 +2910,52 @@ kms_writeback@writeback-invalid-parameters kms_writeback@writeback-fb-id kms_writeback@writeback-check-output prime_mmap_kms@buffer-sharing +msm_shrink@copy-gpu-sanitycheck-8 +msm_shrink@copy-gpu-sanitycheck-32 +msm_shrink@copy-gpu-8 +msm_shrink@copy-gpu-32 +msm_shrink@copy-gpu-madvise-8 +msm_shrink@copy-gpu-madvise-32 +msm_shrink@copy-gpu-oom-8 +msm_shrink@copy-gpu-oom-32 +msm_shrink@copy-mmap-sanitycheck-8 +msm_shrink@copy-mmap-sanitycheck-32 +msm_shrink@copy-mmap-8 +msm_shrink@copy-mmap-32 +msm_shrink@copy-mmap-madvise-8 +msm_shrink@copy-mmap-madvise-32 +msm_shrink@copy-mmap-oom-8 +msm_shrink@copy-mmap-oom-32 +msm_shrink@copy-mmap-dmabuf-sanitycheck-8 +msm_shrink@copy-mmap-dmabuf-sanitycheck-32 +msm_shrink@copy-mmap-dmabuf-8 +msm_shrink@copy-mmap-dmabuf-32 +msm_shrink@copy-mmap-dmabuf-madvise-8 +msm_shrink@copy-mmap-dmabuf-madvise-32 +msm_shrink@copy-mmap-dmabuf-oom-8 +msm_shrink@copy-mmap-dmabuf-oom-32 +msm_mapping@ring +msm_mapping@sqefw +msm_mapping@shadow +msm_submitoverhead@submitbench-10-bos +msm_submitoverhead@submitbench-10-bos-no-implicit-sync +msm_submitoverhead@submitbench-100-bos +msm_submitoverhead@submitbench-100-bos-no-implicit-sync +msm_submitoverhead@submitbench-250-bos +msm_submitoverhead@submitbench-250-bos-no-implicit-sync +msm_submitoverhead@submitbench-500-bos +msm_submitoverhead@submitbench-500-bos-no-implicit-sync +msm_submitoverhead@submitbench-1000-bos +msm_submitoverhead@submitbench-1000-bos-no-implicit-sync +msm_recovery@hangcheck +msm_recovery@gpu-fault +msm_recovery@gpu-fault-parallel +msm_recovery@iova-fault +msm_submit@empty-submit +msm_submit@invalid-queue-submit +msm_submit@invalid-flags-submit +msm_submit@invalid-in-fence-submit +msm_submit@invalid-duplicate-bo-submit +msm_submit@invalid-cmd-idx-submit +msm_submit@invalid-cmd-type-submit +msm_submit@valid-submit
Re: [PATCH 1/3] drm/nouveau: include drm/drm_edid.h only where needed
On 1/9/24 10:59, Jani Nikula wrote:
On Mon, 08 Jan 2024, Danilo Krummrich wrote:
On 1/4/24 21:16, Jani Nikula wrote:
Including drm_edid.h from nouveau_connector.h causes the rebuild of 15
files when drm_edid.h is modified, while there are only a few files that
actually need to include drm_edid.h.
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Danilo Krummrich
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jani Nikula
Reviewed-by: Danilo Krummrich
Are you going to pick this up via the nouveau tree, or shall I apply it
to drm-misc-next?
We don't maintain a separate tree, hence feel free to apply it to drm-misc-next.
- Danilo
BR,
Jani.
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 1 +
drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 5f490fbf1877..83355dbc15ee 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include "nouveau_connector.h"
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h
index a2df4918340c..0608cabed058 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -35,7 +35,6 @@
#include
#include
-#include
#include
#include
@@ -44,6 +43,7 @@
struct nvkm_i2c_port;
struct dcb_output;
+struct edid;
#ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
struct nouveau_backlight {
Re: [PATCH RFC v2 02/11] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
On 1/9/24 5:32 AM, Krzysztof Kozlowski wrote:
On 08/01/2024 19:32, Andrew Davis wrote:
The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors. Describe how the SGX GPU is integrated in these SoC,
including register space and interrupts. Clocks, reset, and power domain
information is SoC specific.
Signed-off-by: Andrew Davis
---
.../bindings/gpu/img,powervr-sgx.yaml | 124 ++
MAINTAINERS | 1 +
2 files changed, 125 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
new file mode 100644
index 0..bb821e1184de9
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 Imagination Technologies Ltd.
Your email has @TI domain, are you sure you attribute your copyrights to
Imagination?
The file started as a copy/paste from a IMG copyrighted file, even
though it is now almost completely re-written I've left their (c)
for good measure. I'll add an additional TI (c).
...
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks: true
Missing min/maxItems
These are set in the allOf/if/then blocks below, seems
if I don't set them to at least something here then I get
a warning:
'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
even if I define them in the allOf block below. I don't
know what the min/max should be until I check the compatible
in the allOf block.
+
+ clock-names:
+minItems: 1
+items:
+ - const: core
+ - const: mem
+ - const: sys
+
+ power-domains:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
This goes after allOf: block.
ACK
+
+allOf:
+ - if:
+ properties:
+compatible:
+ contains:
+const: ti,am6548-gpu
+then:
+ required:
+- power-domains
+else:
+ properties:
+power-domains: false
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - allwinner,sun6i-a31-gpu
+ - ingenic,jz4780-gpu
+then:
+ allOf:
+- if:
I don't understand why do you need to embed allOf inside another allOf.
The upper (outer) if:then: looks entirely useless.
It is so that both compatibles falls through to having
clock being required.
Logic in YAML always seems messy to me, here it is in pseudo C:
if (compatible == allwinner,sun6i-a31-gpu ||
compatible == ingenic,jz4780-gpu) {
if (compatible == allwinner,sun6i-a31-gpu)
clocks: ...
if (compatible == ingenic,jz4780-gpu)
clocks: ...
required:
- clocks
- clock-names
} else { /* disallow for all others */
properties:
clocks: false
clock-names: false
}
Now if I had an "else if" that didn't force the indention to keep
growing I would have used that. (does one exist?) I also cannot
simply add the clock properties only for the two compats need
them for the reasons above and so must add them unconditionally
before then explicitly disable them in a catch-all else path.
Andrew
+properties:
+ compatible:
+contains:
+ const: allwinner,sun6i-a31-gpu
+ then:
+properties:
+ clocks:
+minItems: 2
+maxItems: 2
+ clock-names:
+minItems: 2
+maxItems: 2
Best regards,
Krzysztof
Re: [PATCH v2] drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable()
Hi,
On Tue, Jan 9, 2024 at 4:05 AM Pin-yen Lin wrote:
>
> The ps8640 bridge seems to expect everything to be power cycled at the
> disable process, but sometimes ps8640_aux_transfer() holds the runtime
> PM reference and prevents the bridge from suspend.
>
> Prevent that by introducing a mutex lock between ps8640_aux_transfer()
> and .post_disable() to make sure the bridge is really powered off.
>
> Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power
> management")
> Signed-off-by: Pin-yen Lin
> ---
>
> Changes in v2:
> - Use mutex instead of the completion and autosuspend hack
>
> drivers/gpu/drm/bridge/parade-ps8640.c | 16
> 1 file changed, 16 insertions(+)
This looks OK to me now.
Reviewed-by: Douglas Anderson
I'll let it stew on the mailing list for ~1 week and then land it in
drm-misc-fixes unless there are additional comments.
-Doug
Re: [PATCH] drm/xe: clean up type of GUC_HXG_MSG_0_ORIGIN
On 08.01.2024 22:24, Lucas De Marchi wrote:
> On Mon, Jan 08, 2024 at 09:46:47PM +0100, Michal Wajdeczko wrote:
>>
>>
>> On 08.01.2024 15:07, Lucas De Marchi wrote:
>>> On Mon, Jan 08, 2024 at 12:05:57PM +0300, Dan Carpenter wrote:
The GUC_HXG_MSG_0_ORIGIN definition should be unsigned. Currently
it is
defined as INT_MIN. This doesn't cause a problem currently but it's
still worth cleaning up.
Signed-off-by: Dan Carpenter
>>>
>>> it seems there are a few more places to change to follow what was done
>>> in commit 962bd34bb457 ("drm/i915/uc: Fix undefined behavior due to
>>> shift overflowing the constant").
>>>
>>> +Michal
>>>
>>> Could we eventually share these abi includes with i915 so we don't
>>> keep fixing the same thing in 2 places?
>>
>> it should be possible and I guess we should plan for that while
>> discussing all this new xe driver...
>>
>> anyway, what about creating new intel/ folder under drm/ ?
>
> include/drm/intel/?
maybe, but then we will be limited to pure definitions/inlines, while I
hope we could separate more GuC firmware specific, but still driver
agnostic, code and place it under drivers/gpu/drm/intel/
drivers/gpu/drm/intel/
include/
abi/
guc_actions_abi.h
guc_errors_abi.h
guc_klvs_abi.h
guc/
guc_hxg_helpers.c
guc_log_helpers.c
note that AMD has its definitions in drm/amd/include/ not under include/
>
>>
>> - drm/intel/include/abi
>> guc_actions_abi.h
>> guc_klvs_abi.h
>> ...
>>
>> the only question would be what prefix should be used for macros:
>> just GUC_ or INTEL_GUC_ or XE_GUC_ ?
>
> if using a intel/ dir, probably better with INTEL_ prefix
>
>>
>> then we can also think of creating library with common helpers for GuC
>> (for encoding/decoding HXG messages, preparing ADS, reading logs, etc)
>
> with the other differences we have, I don't see much benefit,
> particularly as it won't change for i915 wrt supported platforms.
we are still using unified firmware versions across different platforms,
so any newer firmware version drops could still be beneficial for the
i915 and those legacy platforms
>
>>
>> btw, we can also consider sharing register definitions:
>>
>> - drm/intel/include/regs
>> xe_engine_regs.h
>> xe_gt_regs.h
>> xe_regs_defs.h
>
> same as above, I don't think it's worth it as xe will keep adding to it
> and it doesn't care for all the previous platforms. For those files we
> may eventually autogen them like done by mesa.
autogen sounds promising, so lets wait and once this will happen we can
abandon xe/regs
>
> Lucas De Marchi
>
>>
>> Michal
>>
>>>
>>> Lucas De Marchi
>>>
---
drivers/gpu/drm/xe/abi/guc_messages_abi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/abi/guc_messages_abi.h
b/drivers/gpu/drm/xe/abi/guc_messages_abi.h
index 3d199016cf88..c04606872e48 100644
--- a/drivers/gpu/drm/xe/abi/guc_messages_abi.h
+++ b/drivers/gpu/drm/xe/abi/guc_messages_abi.h
@@ -40,7 +40,7 @@
*/
#define GUC_HXG_MSG_MIN_LEN 1u
-#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31)
+#define GUC_HXG_MSG_0_ORIGIN (0x1U << 31)
#define GUC_HXG_ORIGIN_HOST 0u
#define GUC_HXG_ORIGIN_GUC 1u
#define GUC_HXG_MSG_0_TYPE (0x7 << 28)
--
2.42.0
Re: [PATCH v2 1/2] dt-bindings: display: panel: panel-simple: Add compatible property for waveshare 7inch touchscreen panel
On Tue, Jan 09, 2024 at 03:09:48PM +0800, Shengyang Chen wrote: > The waveshare 7" 800x480 panel is a clone of Raspberry Pi 7" 800x480 panel > It can be drived by Raspberry Pi panel's process but it needs different > timing from Raspberry Pi panel. Add compatible property for it. > > Signed-off-by: Keith Zhao > Signed-off-by: Shengyang Chen > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 11422af3477e..02f6b1b2ddc9 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -335,6 +335,8 @@ properties: >- vivax,tpc9150-panel > # VXT 800x480 color TFT LCD panel >- vxt,vl050-8048nt-c01 > +# Waveshare 7" (800x480) touchscreen LCD panel > + - waveshare,7inch-touchscreen Is "7inch-touchscreen" really a specific enough identifier for this device? > # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel >- winstar,wf35ltiacd > # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel > -- > 2.17.1 > signature.asc Description: PGP signature
Re: [DO NOT MERGE v6 19/37] dt-bindings: interrupt-controller: renesas,sh7751-irl-ext: Add json-schema
On Tue, 09 Jan 2024 17:23:16 +0900, Yoshinori Sato wrote: > Renesas SH7751 external interrupt encoder json-schema. > > Signed-off-by: Yoshinori Sato > --- > .../renesas,sh7751-irl-ext.yaml | 72 +++ > 1 file changed, 72 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.example.dtb: sh7751irl_encoder@a400: '#size-cells' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-irl-ext.yaml# doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/a801115c277e65341da079c318a1b970f8d9e671.1704788539.git.ys...@users.sourceforge.jp The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
Re: [PATCH RFC v2 01/11] dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
On 1/9/24 5:28 AM, Krzysztof Kozlowski wrote:
On 08/01/2024 19:32, Andrew Davis wrote:
Signed-off-by: Andrew Davis
---
.../bindings/gpu/{img,powervr.yaml => img,powervr-rogue.yaml} | 4 ++--
MAINTAINERS | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
If you are renaming it, why not renaming to match compatible as we
usually expect?
There are (or will be) multiple compatible strings described in this
file, naming the file after just one would not fully convey the content
of the file. This generic style naming seems common already for bindings
with multiple compatibles.
Andrew
Best regards,
Krzysztof
Re: BUG / design challenge: vmwgfx + PRIME handle free == clobbering errno
Hi, KWin does use DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT. Tying the check to DRM_CLIENT_CAP_ATOMIC instead would IMO make more sense though (even if it's still weird) and would work with older versions of KWin and other compositors. Greetings, Xaver Hugl
Re: [PATCH v2] drm/vram-helper: fix kernel-doc warnings
On Tue, 9 Jan 2024 at 16:29, Randy Dunlap wrote:
>
>
>
> On 1/9/24 07:25, Daniel Vetter wrote:
> > On Tue, 9 Jan 2024 at 16:23, Randy Dunlap wrote:
> >>
> >>
> >>
> >> On 1/9/24 05:42, Daniel Vetter wrote:
> >>> On Tue, 9 Jan 2024 at 13:59, Daniel Vetter wrote:
>
> On Mon, Jan 08, 2024 at 01:10:12PM -0800, Randy Dunlap wrote:
> > Hi Thomas,
> >
> > On 1/8/24 00:57, Thomas Zimmermann wrote:
> >> Hi,
> >>
> >> thanks for the fix.
> >>
> >> Am 06.01.24 um 04:29 schrieb Randy Dunlap:
> >>> Remove the @funcs entry from struct drm_vram_mm to quieten the
> >>> kernel-doc
> >>> warning.
> >>>
> >>> Use the "define" kernel-doc keyword and an '\' line continuation
> >>> to fix another kernel-doc warning.
> >>>
> >>> drm_gem_vram_helper.h:129: warning: missing initial short description
> >>> on line:
> >>> * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> >>> drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs'
> >>> description in 'drm_vram_mm'
> >>>
> >>> Signed-off-by: Randy Dunlap
> >>> Cc: David Airlie
> >>> Cc: Daniel Vetter
> >>> Cc: dri-devel@lists.freedesktop.org
> >>> Cc: Maarten Lankhorst
> >>> Cc: Maxime Ripard
> >>> Cc: Thomas Zimmermann
> >>> ---
> >>> v2: Add commit description
> >>>
> >>> base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
> >>>
> >>> include/drm/drm_gem_vram_helper.h |3 +--
> >>> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>>
> >>> diff -- a/include/drm/drm_gem_vram_helper.h
> >>> b/include/drm/drm_gem_vram_helper.h
> >>> --- a/include/drm/drm_gem_vram_helper.h
> >>> +++ b/include/drm/drm_gem_vram_helper.h
> >>> @@ -126,7 +126,7 @@ drm_gem_vram_plane_helper_cleanup_fb(str
> >>>struct drm_plane_state *old_state);
> >>> /**
> >>> - * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> >>> + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
> >>
> >> Did something change wrt. doc syntax? I think this used to work
> >> without warnings. About this 'define': we don't use is in another
> >> docs. Can we leave it out here or is this the new syntax?
> >>
> >
> > There are no doc syntax changes that I know of. This is not
> > new syntax. It has been around since 2014:
> > cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros")
>
> I had no idea this exists, thanks a lot for this TIL :-)
>
> I guess the issue here is that this exists, yay, but it's not documented
> with the other here:
>
> https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#structure-union-and-enumeration-documentation
>
> I guess a patch to kernel-doc.rst would be great. Adding some kernel-doc
> folks.
> >>>
> >>> Ok I went ahead and typed that patch (just we don't waste effort),
> >>> just waiting for the sphinx build to finish to make sure it looks nice
> >>> before I send out the patch.
> >>> -Sima
> >>
> >> I sent one a few days ago:
> >>
> >> https://lore.kernel.org/lkml/20240107012400.32587-1-rdun...@infradead.org/
> >
> > Could you please also add documentation for function-like macros,
> > since that's also missing? With that acked-by: me.
> >
> > Cheers!
>
> This is already present:
>
> Function documentation
> --
>
> The general format of a function and function-like macro kernel-doc comment
> is::
>
> /**
>* function_name() - Brief description of function.
>* @arg1: Describe the first argument.
>* @arg2: Describe the second argument.
>*One can provide multiple line descriptions
>*for arguments.
>
>
> but the way that you did it makes sense also.
Ah missed that it includes wording for function-like macros. On your
patch as-is:
Acked-by: Daniel Vetter
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH] drm/ci: Add msm tests
On Mon, Jan 8, 2024 at 6:13 PM Rob Clark wrote: > > On Mon, Jan 8, 2024 at 2:58 PM Abhinav Kumar > wrote: > > > > > > > > On 1/8/2024 11:50 AM, Rob Clark wrote: > > > From: Rob Clark > > > > > > The msm tests should skip on non-msm hw, so I think it should be safe to > > > enable everywhere. > > > > > > Signed-off-by: Rob Clark > > > --- > > > drivers/gpu/drm/ci/testlist.txt | 49 + > > > 1 file changed, 49 insertions(+) > > > > > > > I do see that all these tests use igt_msm_dev_open() to make sure it > > opens only the MSM card. > > > > But if igt_msm_dev_open() fails, I dont see a igt_require() on some of > > the tests to skip them. So how will it safely skip on non-msm HW? > > > > Unless i am missing something here > > hmm, at the time I added the initial msm tests, and > igt_msm_dev_open(), I verified that they skipped on intel.. but since > then I'd switched from intel to sc8280xp device for primary dev > device, so I'd need to re-test to remember how it works. If these > aren't skipping on !msm, it is a bug I double checked, these tests skip in drm_open_driver() with "No known gpu found for chipset flags 0x64 (msm)", so no problem to run them on all CI runners. BR, -R > BR, > -R > > > > diff --git a/drivers/gpu/drm/ci/testlist.txt > > > b/drivers/gpu/drm/ci/testlist.txt > > > index f82cd90372f4..eaeb751bb0ad 100644 > > > --- a/drivers/gpu/drm/ci/testlist.txt > > > +++ b/drivers/gpu/drm/ci/testlist.txt > > > @@ -2910,3 +2910,52 @@ kms_writeback@writeback-invalid-parameters > > > kms_writeback@writeback-fb-id > > > kms_writeback@writeback-check-output > > > prime_mmap_kms@buffer-sharing > > > +msm_shrink@copy-gpu-sanitycheck-8 > > > +msm_shrink@copy-gpu-sanitycheck-32 > > > +msm_shrink@copy-gpu-8 > > > +msm_shrink@copy-gpu-32 > > > +msm_shrink@copy-gpu-madvise-8 > > > +msm_shrink@copy-gpu-madvise-32 > > > +msm_shrink@copy-gpu-oom-8 > > > +msm_shrink@copy-gpu-oom-32 > > > +msm_shrink@copy-mmap-sanitycheck-8 > > > +msm_shrink@copy-mmap-sanitycheck-32 > > > +msm_shrink@copy-mmap-8 > > > +msm_shrink@copy-mmap-32 > > > +msm_shrink@copy-mmap-madvise-8 > > > +msm_shrink@copy-mmap-madvise-32 > > > +msm_shrink@copy-mmap-oom-8 > > > +msm_shrink@copy-mmap-oom-32 > > > +msm_shrink@copy-mmap-dmabuf-sanitycheck-8 > > > +msm_shrink@copy-mmap-dmabuf-sanitycheck-32 > > > +msm_shrink@copy-mmap-dmabuf-8 > > > +msm_shrink@copy-mmap-dmabuf-32 > > > +msm_shrink@copy-mmap-dmabuf-madvise-8 > > > +msm_shrink@copy-mmap-dmabuf-madvise-32 > > > +msm_shrink@copy-mmap-dmabuf-oom-8 > > > +msm_shrink@copy-mmap-dmabuf-oom-32 > > > +msm_mapping@ring > > > +msm_mapping@sqefw > > > +msm_mapping@shadow > > > +msm_submitoverhead@submitbench-10-bos > > > +msm_submitoverhead@submitbench-10-bos-no-implicit-sync > > > +msm_submitoverhead@submitbench-100-bos > > > +msm_submitoverhead@submitbench-100-bos-no-implicit-sync > > > +msm_submitoverhead@submitbench-250-bos > > > +msm_submitoverhead@submitbench-250-bos-no-implicit-sync > > > +msm_submitoverhead@submitbench-500-bos > > > +msm_submitoverhead@submitbench-500-bos-no-implicit-sync > > > +msm_submitoverhead@submitbench-1000-bos > > > +msm_submitoverhead@submitbench-1000-bos-no-implicit-sync > > > +msm_recovery@hangcheck > > > +msm_recovery@gpu-fault > > > +msm_recovery@gpu-fault-parallel > > > +msm_recovery@iova-fault > > > +msm_submit@empty-submit > > > +msm_submit@invalid-queue-submit > > > +msm_submit@invalid-flags-submit > > > +msm_submit@invalid-in-fence-submit > > > +msm_submit@invalid-duplicate-bo-submit > > > +msm_submit@invalid-cmd-idx-submit > > > +msm_submit@invalid-cmd-type-submit > > > +msm_submit@valid-submit
Re: [PATCH v2] drm/vram-helper: fix kernel-doc warnings
On 1/9/24 07:25, Daniel Vetter wrote:
> On Tue, 9 Jan 2024 at 16:23, Randy Dunlap wrote:
>>
>>
>>
>> On 1/9/24 05:42, Daniel Vetter wrote:
>>> On Tue, 9 Jan 2024 at 13:59, Daniel Vetter wrote:
On Mon, Jan 08, 2024 at 01:10:12PM -0800, Randy Dunlap wrote:
> Hi Thomas,
>
> On 1/8/24 00:57, Thomas Zimmermann wrote:
>> Hi,
>>
>> thanks for the fix.
>>
>> Am 06.01.24 um 04:29 schrieb Randy Dunlap:
>>> Remove the @funcs entry from struct drm_vram_mm to quieten the
>>> kernel-doc
>>> warning.
>>>
>>> Use the "define" kernel-doc keyword and an '\' line continuation
>>> to fix another kernel-doc warning.
>>>
>>> drm_gem_vram_helper.h:129: warning: missing initial short description
>>> on line:
>>> * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
>>> drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs'
>>> description in 'drm_vram_mm'
>>>
>>> Signed-off-by: Randy Dunlap
>>> Cc: David Airlie
>>> Cc: Daniel Vetter
>>> Cc: dri-devel@lists.freedesktop.org
>>> Cc: Maarten Lankhorst
>>> Cc: Maxime Ripard
>>> Cc: Thomas Zimmermann
>>> ---
>>> v2: Add commit description
>>>
>>> base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
>>>
>>> include/drm/drm_gem_vram_helper.h |3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff -- a/include/drm/drm_gem_vram_helper.h
>>> b/include/drm/drm_gem_vram_helper.h
>>> --- a/include/drm/drm_gem_vram_helper.h
>>> +++ b/include/drm/drm_gem_vram_helper.h
>>> @@ -126,7 +126,7 @@ drm_gem_vram_plane_helper_cleanup_fb(str
>>>struct drm_plane_state *old_state);
>>> /**
>>> - * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
>>> + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
>>
>> Did something change wrt. doc syntax? I think this used to work without
>> warnings. About this 'define': we don't use is in another docs. Can we
>> leave it out here or is this the new syntax?
>>
>
> There are no doc syntax changes that I know of. This is not
> new syntax. It has been around since 2014:
> cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros")
I had no idea this exists, thanks a lot for this TIL :-)
I guess the issue here is that this exists, yay, but it's not documented
with the other here:
https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#structure-union-and-enumeration-documentation
I guess a patch to kernel-doc.rst would be great. Adding some kernel-doc
folks.
>>>
>>> Ok I went ahead and typed that patch (just we don't waste effort),
>>> just waiting for the sphinx build to finish to make sure it looks nice
>>> before I send out the patch.
>>> -Sima
>>
>> I sent one a few days ago:
>>
>> https://lore.kernel.org/lkml/20240107012400.32587-1-rdun...@infradead.org/
>
> Could you please also add documentation for function-like macros,
> since that's also missing? With that acked-by: me.
>
> Cheers!
This is already present:
Function documentation
--
The general format of a function and function-like macro kernel-doc comment is::
/**
* function_name() - Brief description of function.
* @arg1: Describe the first argument.
* @arg2: Describe the second argument.
*One can provide multiple line descriptions
*for arguments.
but the way that you did it makes sense also.
--
#Randy
Re: [PATCH] nightly.conf: Reorder the xe repo URLs
On Tue, Jan 09, 2024 at 04:00:15PM +0100, Thomas Hellström wrote: Select the https URL by default for xe since users may not have registered a gitlab ssh key yet, and may get confused by the corresponding error message. Suggested-by: Daniel Vetter Cc: intel...@lists.freedesktop.org Cc: Lucas De Marchi Signed-off-by: Thomas Hellström Reviewed-by: Lucas De Marchi Lucas De Marchi --- nightly.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/nightly.conf b/nightly.conf index accd3ff2cc39..84dbdb98a99f 100644 --- a/nightly.conf +++ b/nightly.conf @@ -25,8 +25,8 @@ https://anongit.freedesktop.org/git/drm/drm-tip https://anongit.freedesktop.org/git/drm/drm-tip.git " drm_tip_repos[drm-xe]=" -ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git https://gitlab.freedesktop.org/drm/xe/kernel.git +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git " drm_tip_repos[drm-intel]=" ssh://git.freedesktop.org/git/drm/drm-intel -- 2.43.0
Re: [PATCH v2] drm/vram-helper: fix kernel-doc warnings
On Tue, 9 Jan 2024 at 16:23, Randy Dunlap wrote:
>
>
>
> On 1/9/24 05:42, Daniel Vetter wrote:
> > On Tue, 9 Jan 2024 at 13:59, Daniel Vetter wrote:
> >>
> >> On Mon, Jan 08, 2024 at 01:10:12PM -0800, Randy Dunlap wrote:
> >>> Hi Thomas,
> >>>
> >>> On 1/8/24 00:57, Thomas Zimmermann wrote:
> Hi,
>
> thanks for the fix.
>
> Am 06.01.24 um 04:29 schrieb Randy Dunlap:
> > Remove the @funcs entry from struct drm_vram_mm to quieten the
> > kernel-doc
> > warning.
> >
> > Use the "define" kernel-doc keyword and an '\' line continuation
> > to fix another kernel-doc warning.
> >
> > drm_gem_vram_helper.h:129: warning: missing initial short description
> > on line:
> > * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> > drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs'
> > description in 'drm_vram_mm'
> >
> > Signed-off-by: Randy Dunlap
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > ---
> > v2: Add commit description
> >
> > base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
> >
> > include/drm/drm_gem_vram_helper.h |3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff -- a/include/drm/drm_gem_vram_helper.h
> > b/include/drm/drm_gem_vram_helper.h
> > --- a/include/drm/drm_gem_vram_helper.h
> > +++ b/include/drm/drm_gem_vram_helper.h
> > @@ -126,7 +126,7 @@ drm_gem_vram_plane_helper_cleanup_fb(str
> >struct drm_plane_state *old_state);
> > /**
> > - * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> > + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
>
> Did something change wrt. doc syntax? I think this used to work without
> warnings. About this 'define': we don't use is in another docs. Can we
> leave it out here or is this the new syntax?
>
> >>>
> >>> There are no doc syntax changes that I know of. This is not
> >>> new syntax. It has been around since 2014:
> >>> cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros")
> >>
> >> I had no idea this exists, thanks a lot for this TIL :-)
> >>
> >> I guess the issue here is that this exists, yay, but it's not documented
> >> with the other here:
> >>
> >> https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#structure-union-and-enumeration-documentation
> >>
> >> I guess a patch to kernel-doc.rst would be great. Adding some kernel-doc
> >> folks.
> >
> > Ok I went ahead and typed that patch (just we don't waste effort),
> > just waiting for the sphinx build to finish to make sure it looks nice
> > before I send out the patch.
> > -Sima
>
> I sent one a few days ago:
>
> https://lore.kernel.org/lkml/20240107012400.32587-1-rdun...@infradead.org/
Could you please also add documentation for function-like macros,
since that's also missing? With that acked-by: me.
Cheers!
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH v2] drm/vram-helper: fix kernel-doc warnings
On 1/9/24 05:42, Daniel Vetter wrote:
> On Tue, 9 Jan 2024 at 13:59, Daniel Vetter wrote:
>>
>> On Mon, Jan 08, 2024 at 01:10:12PM -0800, Randy Dunlap wrote:
>>> Hi Thomas,
>>>
>>> On 1/8/24 00:57, Thomas Zimmermann wrote:
Hi,
thanks for the fix.
Am 06.01.24 um 04:29 schrieb Randy Dunlap:
> Remove the @funcs entry from struct drm_vram_mm to quieten the kernel-doc
> warning.
>
> Use the "define" kernel-doc keyword and an '\' line continuation
> to fix another kernel-doc warning.
>
> drm_gem_vram_helper.h:129: warning: missing initial short description on
> line:
> * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs'
> description in 'drm_vram_mm'
>
> Signed-off-by: Randy Dunlap
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> ---
> v2: Add commit description
>
> base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
>
> include/drm/drm_gem_vram_helper.h |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff -- a/include/drm/drm_gem_vram_helper.h
> b/include/drm/drm_gem_vram_helper.h
> --- a/include/drm/drm_gem_vram_helper.h
> +++ b/include/drm/drm_gem_vram_helper.h
> @@ -126,7 +126,7 @@ drm_gem_vram_plane_helper_cleanup_fb(str
>struct drm_plane_state *old_state);
> /**
> - * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
Did something change wrt. doc syntax? I think this used to work without
warnings. About this 'define': we don't use is in another docs. Can we
leave it out here or is this the new syntax?
>>>
>>> There are no doc syntax changes that I know of. This is not
>>> new syntax. It has been around since 2014:
>>> cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros")
>>
>> I had no idea this exists, thanks a lot for this TIL :-)
>>
>> I guess the issue here is that this exists, yay, but it's not documented
>> with the other here:
>>
>> https://dri.freedesktop.org/docs/drm/doc-guide/kernel-doc.html#structure-union-and-enumeration-documentation
>>
>> I guess a patch to kernel-doc.rst would be great. Adding some kernel-doc
>> folks.
>
> Ok I went ahead and typed that patch (just we don't waste effort),
> just waiting for the sphinx build to finish to make sure it looks nice
> before I send out the patch.
> -Sima
I sent one a few days ago:
https://lore.kernel.org/lkml/20240107012400.32587-1-rdun...@infradead.org/
--
#Randy
Re: [PATCH] drm/imagination: Defer probe if requested firmware is not available
Daniel Vetter writes:
> On Tue, Jan 09, 2024 at 02:48:42PM +0100, Javier Martinez Canillas wrote:
>> Daniel Vetter writes:
>>
>> Hello Sima,
>>
>> Thanks for your feedback.
>>
>> > On Tue, Jan 09, 2024 at 01:05:59PM +0100, Javier Martinez Canillas wrote:
>> >> The device is initialized in the driver's probe callback and as part of
>> >> that initialization, the required firmware is loaded. But this fails if
>> >> the driver is built-in and the firmware isn't present in the initramfs:
>> >>
>> >> $ dmesg | grep powervr
>> >> [2.969757] powervr fd0.gpu: Direct firmware load for
>> >> powervr/rogue_33.15.11.3_v1.fw failed with error -2
>> >> [2.979727] powervr fd0.gpu: [drm] *ERROR* failed to load firmware
>> >> powervr/rogue_33.15.11.3_v1.fw (err=-2)
>> >> [2.989885] powervr: probe of fd0.gpu failed with error -2
>> >>
>> >> $ ls -lh /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
>> >> -rw-r--r-- 1 root root 51K Dec 12 19:00
>> >> /lib/firmware/powervr/rogue_33.15.11.3_v1.fw.xz
>> >>
>> >> To prevent the probe to fail for this case, let's defer the probe if the
>> >> firmware isn't available. That way, the driver core can retry it and get
>> >> the probe to eventually succeed once the root filesystem has been mounted.
>> >>
>> >> If the firmware is also not present in the root filesystem, then the probe
>> >> will never succeed and the reason listed in the debugfs devices_deferred:
>> >>
>> >> $ cat /sys/kernel/debug/devices_deferred
>> >> fd0.gpu powervr: failed to load firmware
>> >> powervr/rogue_33.15.11.3_v1.fw (err=-517)
>> >>
>> >> Fixes: f99f5f3ea7ef ("drm/imagination: Add GPU ID parsing and firmware
>> >> loading")
>> >> Suggested-by: Maxime Ripard
>> >> Signed-off-by: Javier Martinez Canillas
>> >
>> > Uh that doesn't work.
>> >
>> > Probe is for "I'm missing a struct device" and _only_ that. You can't
>> > assume that probe deferral will defer enough until the initrd shows up.
>> >
>>
>> Fair.
>>
>> > You need to fix this by fixing the initrd to include the required
>> > firmwares. This is what MODULE_FIRMWARE is for, and if your initrd fails
>> > to observe that it's just broken.
>> >
>>
>> Tha's already the case, when is built as a module the initrd (dracut in
>> this particular case) does figure out that the firmware needs to be added
>> but that doesn't work when the DRM driver is built-in. Because dracut is
>> not able to figure out and doesn't even have a powervr.ko info to look at
>> whatever is set by the MODULE_FIRMWARE macro.
>
> Yeah built-in drivers that require firmware don't really work. I'm not
> sure it changed, but a while ago you had to actually include these in the
> kernel image itself (initrd was again too late), and that gives you
> something you can't even ship because it links blobs with gplv2 kernel.
>
Indeed and even let the legal question aside, doing that makes the kernel
too platform specific, even more than building drivers in.
> Maybe that changed and the initramfs is set up early enough now that it's
> sufficient to have it there ...
>
It does work if I force to include the firmware file in the initrd, e.g:
$ cat /etc/dracut.conf.d/firmware.conf
install_items+=" /lib/firmware/powervr/rogue_33.15.11.3_v1.fw "
> Either way I think this needs module/kernel-image build changes so that
> the list of firmware images needed for the kernel itself is dumped
> somewhere, so that dracut can consume it and tdrt. My take at least.
>
That's a very good idea indeed. Dracut just looking at loaded modules and
their respective module info doesn't really work for built-in drivers...
>> > Yes I know as long as you have enough stuff built as module so that there
>> > will be _any_ kind of device probe after the root fs is mounted, this
>> > works, because that triggers a re-probe of everything. But that's the most
>> > kind of fragile fix there is.
>> >
>>
>> Is fragile that's true but on the other hand it does solve the issue in
>> pratice. The whole device probal mechanism is just a best effort anyways.
>>
>> > If you want to change that then I think that needs an official blessing
>> > from Greg KH/device core folks.
>> >
Ok. Let's see what Greg says, I think $SUBJECT is the path of least
resistance and something that is simple enough that could be easy to
backport / cherry-pick if needed.
But also agree with you that it's fragile (just like the driver as is).
Something that I forgot to mention but came up in our IRC discussion is
that the powervr driver is render only, so deferring the probe won't
affect the display that's driven by a different driver (tidss in my case).
>>
>> I liked this approach due its simplicity but an alternative (and more
>> complex) solution could be to delay the firmware request and not do it at
>> probe time.
>>
>> For example, the following (only barely tested) patch solves the issue for
>> me as well but it's a bigger change to this driver and wasn't sure if will
>> be acceptable:
>
Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats
On 09/01/2024 14:57, Christian König wrote:
Am 09.01.24 um 15:26 schrieb Daniel Vetter:
On Tue, 9 Jan 2024 at 14:25, Tvrtko Ursulin
wrote:
On 09/01/2024 12:54, Daniel Vetter wrote:
On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:
On 09/01/2024 07:56, Christian König wrote:
Am 07.12.23 um 19:02 schrieb Alex Deucher:
Add shared stats. Useful for seeing shared memory.
v2: take dma-buf into account as well
Signed-off-by: Alex Deucher
Cc: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 6 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index 5706b282a0c7..c7df7fa3459f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p,
struct drm_file *file)
stats.requested_visible_vram/1024UL);
drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
stats.requested_gtt/1024UL);
+ drm_printf(p, "drm-shared-vram:\t%llu KiB\n",
stats.vram_shared/1024UL);
+ drm_printf(p, "drm-shared-gtt:\t%llu KiB\n",
stats.gtt_shared/1024UL);
+ drm_printf(p, "drm-shared-cpu:\t%llu KiB\n",
stats.cpu_shared/1024UL);
+
for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
if (!usage[hw_ip])
continue;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index d79b4ca1ecfc..1b37d95475b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct
amdgpu_bo *bo,
struct amdgpu_mem_stats *stats)
{
uint64_t size = amdgpu_bo_size(bo);
+ struct drm_gem_object *obj;
unsigned int domain;
+ bool shared;
/* Abort if the BO doesn't currently have a backing store */
if (!bo->tbo.resource)
return;
+ obj = >tbo.base;
+ shared = (obj->handle_count > 1) || obj->dma_buf;
I still think that looking at handle_count is the completely wrong
approach, we should really only look at obj->dma_buf.
Yeah it is all a bit tricky with the handle table walk. I don't
think it is
even possible to claim it is shared with obj->dma_buf could be the
same
process creating say via udmabuf and importing into drm. It is a wild
scenario yes, but it could be private memory in that case. Not sure
where it
would leave us if we said this is just a limitation of a BO based
tracking.
Would adding a new category "imported" help?
Hmm or we simply change drm-usage-stats.rst:
"""
- drm-shared-: [KiB|MiB]
The total size of buffers that are shared with another file (ie.
have more
than than a single handle).
"""
Changing ie into eg coule be get our of jail free card to allow the
"(obj->handle_count > 1) || obj->dma_buf;" condition?
Because of the shared with another _file_ wording would cover my wild
udmabuf self-import case. Unless there are more such creative
private import
options.
Yeah I think clarifying that we can only track sharing with other fd
and
have no idea whether this means sharing with another process or not is
probably simplest. Maybe not exactly what users want, but still the
roughly best-case approximation we can deliver somewhat cheaply.
Also maybe time for a drm_gem_buffer_object_is_shared() helper so we
don't
copypaste this all over and then end up in divergent conditions? I'm
guessing that there's going to be a bunch of drivers which needs this
little helper to add drm-shared-* stats to their fdinfo ...
Yeah I agree that works and i915 would need to use the helper too.
I would only suggest to name it so the meaning of shared is obviously
only about the fdinfo memory stats and no one gets a more meaningful
idea about its semantics.
We have drm_show_memory_stats and drm_print_memory_stats exported so
perhaps something like drm_object_is_shared_for_memory_stats,
drm_object_is_memory_stats_shared, drm_memory_stats_object_is_shared?
+ for drm_object_is_shared_for_memory_stats().
Hmmm although I probably meant to write
drm_gem_object_is_shared_for_memory_stats. Since drm_mode_object seems
to have claimed the drm_object_ function name space.
And s/ie/eg/ in the above quoted drm-usage-stats.rst.
Ack on making it clear this helper would be for fdinfo memory stats
only. Sounds like a good idea to stop people from finding really
creative uses ...
It's astonishing how defensive the development process has become :)
A bit. :) But probably justified in this case.
Regards,
Tvrtko
Cheers,
Christian.
-Sima
Regards,
Tvrtko
Cheers, Sima
Regards,
Tvrtko
Regards,
Christian.
+
domain =
amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
switch
