* ✓ Fi.CI.IGT: success for drm/i915: Keep rings pinned while the context is active (rev3)
From: Patchwork @ 2019-06-20 13:30 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20190619153942.8518-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: drm/i915: Keep rings pinned while the context is active (rev3)
URL : https://patchwork.freedesktop.org/series/62388/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6310_full -> Patchwork_13348_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_13348_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_isolation@rcs0-s3:
- shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-apl6/igt@gem_ctx_isolation@rcs0-s3.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-apl5/igt@gem_ctx_isolation@rcs0-s3.html
* igt@gem_eio@wait-immediate:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-apl6/igt@gem_eio@wait-immediate.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-apl1/igt@gem_eio@wait-immediate.html
* igt@gem_mmap_gtt@medium-copy-xy:
- shard-apl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-apl5/igt@gem_mmap_gtt@medium-copy-xy.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-apl6/igt@gem_mmap_gtt@medium-copy-xy.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy:
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +1 similar issue
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-kbl2/igt@gem_userptr_blits@map-fixed-invalidate-busy.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-kbl4/igt@gem_userptr_blits@map-fixed-invalidate-busy.html
* igt@gem_userptr_blits@map-fixed-invalidate-busy-gup:
- shard-snb: [PASS][9] -> [DMESG-WARN][10] ([fdo#110913 ])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-snb1/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-snb5/igt@gem_userptr_blits@map-fixed-invalidate-busy-gup.html
* igt@kms_color@pipe-a-ctm-0-75:
- shard-hsw: [PASS][11] -> [INCOMPLETE][12] ([fdo#103540])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-hsw5/igt@kms_color@pipe-a-ctm-0-75.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-hsw8/igt@kms_color@pipe-a-ctm-0-75.html
* igt@kms_flip@2x-plain-flip:
- shard-hsw: [PASS][13] -> [SKIP][14] ([fdo#109271]) +5 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-hsw7/igt@kms_flip@2x-plain-flip.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-hsw1/igt@kms_flip@2x-plain-flip.html
* igt@kms_flip@flip-vs-suspend:
- shard-snb: [PASS][15] -> [INCOMPLETE][16] ([fdo#105411])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-snb2/igt@kms_flip@flip-vs-suspend.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-snb1/igt@kms_flip@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@fbcpsr-suspend:
- shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108] / [fdo#106978])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-skl4/igt@kms_frontbuffer_tracking@fbcpsr-suspend.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-skl9/igt@kms_frontbuffer_tracking@fbcpsr-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: [PASS][19] -> [INCOMPLETE][20] ([fdo#103665])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-kbl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-kbl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-skl8/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-skl6/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
#### Possible fixes ####
* igt@gem_eio@in-flight-contexts-1us:
- shard-kbl: [DMESG-WARN][23] ([fdo#110913 ]) -> [PASS][24] +1 similar issue
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-kbl2/igt@gem_eio@in-flight-contexts-1us.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-kbl4/igt@gem_eio@in-flight-contexts-1us.html
* igt@gem_eio@wait-10ms:
- shard-apl: [DMESG-WARN][25] ([fdo#110913 ]) -> [PASS][26] +2 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-apl8/igt@gem_eio@wait-10ms.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-apl3/igt@gem_eio@wait-10ms.html
* igt@i915_selftest@live_evict:
- shard-kbl: [INCOMPLETE][27] ([fdo#103665] / [fdo#110938]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-kbl3/igt@i915_selftest@live_evict.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-kbl4/igt@i915_selftest@live_evict.html
* igt@i915_suspend@debugfs-reader:
- shard-apl: [DMESG-WARN][29] ([fdo#108566]) -> [PASS][30]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-apl1/igt@i915_suspend@debugfs-reader.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-apl7/igt@i915_suspend@debugfs-reader.html
* igt@kms_draw_crc@draw-method-rgb565-blt-ytiled:
- shard-skl: [FAIL][31] ([fdo#103184] / [fdo#103232]) -> [PASS][32]
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-skl5/igt@kms_draw_crc@draw-method-rgb565-blt-ytiled.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-skl2/igt@kms_draw_crc@draw-method-rgb565-blt-ytiled.html
* igt@kms_flip@modeset-vs-vblank-race:
- shard-glk: [FAIL][33] ([fdo#103060]) -> [PASS][34]
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-glk6/igt@kms_flip@modeset-vs-vblank-race.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-glk7/igt@kms_flip@modeset-vs-vblank-race.html
* igt@kms_frontbuffer_tracking@fbc-2p-rte:
- shard-hsw: [SKIP][35] ([fdo#109271]) -> [PASS][36] +30 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-hsw1/igt@kms_frontbuffer_tracking@fbc-2p-rte.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-hsw6/igt@kms_frontbuffer_tracking@fbc-2p-rte.html
* igt@kms_setmode@basic:
- shard-hsw: [FAIL][37] ([fdo#99912]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-hsw1/igt@kms_setmode@basic.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-hsw7/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-b-wait-idle:
- shard-snb: [SKIP][39] ([fdo#109271]) -> [PASS][40] +2 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-snb7/igt@kms_vblank@pipe-b-wait-idle.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-snb7/igt@kms_vblank@pipe-b-wait-idle.html
#### Warnings ####
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
- shard-skl: [FAIL][41] ([fdo#108040]) -> [FAIL][42] ([fdo#103167])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-skl5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-skl10/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-skl: [FAIL][43] ([fdo#103167]) -> [FAIL][44] ([fdo#108040])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-skl7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-skl5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt.html
* igt@kms_psr@cursor_mmap_cpu:
- shard-apl: [SKIP][45] ([fdo#109271]) -> [INCOMPLETE][46] ([fdo#103927])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/shard-apl7/igt@kms_psr@cursor_mmap_cpu.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/shard-apl2/igt@kms_psr@cursor_mmap_cpu.html
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106978]: https://bugs.freedesktop.org/show_bug.cgi?id=106978
[fdo#108040]: https://bugs.freedesktop.org/show_bug.cgi?id=108040
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#110913 ]: https://bugs.freedesktop.org/show_bug.cgi?id=110913
[fdo#110938]: https://bugs.freedesktop.org/show_bug.cgi?id=110938
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (10 -> 8)
------------------------------
Missing (2): pig-skl-6260u shard-iclb
Build changes
-------------
* Linux: CI_DRM_6310 -> Patchwork_13348
CI_DRM_6310: dc88bdb699786ec5c75f0fd0fb6f8b0c3e58eb8e @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5061: c88ced79a7b71aec58f1d9c5c599ac2f431bcf7a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13348: 667b1174a18e883b3ab706d5eb309b4710377bae @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13348/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Qemu-devel] [QEMU PATCH v4 0/10]: target/i386: kvm: Add support for save and restore of nested state
From: Liran Alon @ 2019-06-20 13:28 UTC (permalink / raw)
To: Paolo Bonzini
Cc: qemu-devel, ehabkost, kvm, maran.wilson, mtosatti, dgilbert, rth,
jmattson
In-Reply-To: <bcb617b1-7d20-d2ff-81c5-9f165eae5683@redhat.com>
> On 20 Jun 2019, at 15:38, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 19/06/19 18:21, Liran Alon wrote:
>> Hi,
>>
>> This series aims to add support for QEMU to be able to migrate VMs that
>> are running nested hypervisors. In order to do so, it utilizes the new
>> IOCTLs introduced in KVM commit 8fcc4b5923af ("kvm: nVMX: Introduce
>> KVM_CAP_NESTED_STATE") which was created for this purpose.
>
> Applied with just three minor changes that should be uncontroversial:
ACK. Where can I see the applied patches for review?
>
>> 6rd patch updates linux-headers to have updated struct kvm_nested_state.
>> The updated struct now have explicit fields for the data portion.
>
> Changed patch title to "linux-headers: sync with latest KVM headers from
> Linux 5.2”
ACK.
>
>> 7rd patch add vmstate support for saving/restoring kernel integer types (e.g. __u16).
>>
>> 8th patch adds support for saving and restoring nested state in order to migrate
>> guests which run a nested hypervisor.
>
> diff --git a/target/i386/kvm.c b/target/i386/kvm.c
> index e924663f32..f3cf6e1b27 100644
> --- a/target/i386/kvm.c
> +++ b/target/i386/kvm.c
> @@ -1671,10 +1671,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
> struct kvm_vmx_nested_state_hdr *vmx_hdr =
> &env->nested_state->hdr.vmx;
>
> + env->nested_state->format = KVM_STATE_NESTED_FORMAT_VMX;
> vmx_hdr->vmxon_pa = -1ull;
> vmx_hdr->vmcs12_pa = -1ull;
> }
> -
> }
>
> cpu->kvm_msr_buf = g_malloc0(MSR_BUF_SIZE);
>
> which is a no-op since KVM_STATE_NESTED_FORMAT_VMX is zero, but it's tidy.
I agree. My bad. Thanks for adding this :)
>
>> 9th patch add support for KVM_CAP_EXCEPTION_PAYLOAD. This new KVM capability
>> allows userspace to properly distingiush between pending and injecting exceptions.
>>
>> 10th patch changes the nested virtualization migration blocker to only
>> be added when kernel lack support for one of the capabilities required
>> for correct nested migration. i.e. Either KVM_CAP_NESTED_STATE or
>> KVM_CAP_EXCEPTION_PAYLOAD.
>
> Had to disable this for SVM unfortunately.
For backwards compatibility I assume… Sounds reasonable to me so ACK.
Even though I must say I would really like to hear your opinion about the thread I had with David Gilbert regarding QEMU’s migration backwards compatibility:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg622274.html
Thanks for the assistance pushing this forward,
-Liran
^ permalink raw reply
* next/pending-fixes build: 223 builds: 0 failed, 223 passed, 121 warnings (v5.2-rc5-413-gd10f6f2d3e41)
From: kernelci.org bot @ 2019-06-20 13:28 UTC (permalink / raw)
To: linux-next
next/pending-fixes build: 223 builds: 0 failed, 223 passed, 121 warnings (v5.2-rc5-413-gd10f6f2d3e41)
Full Build Summary: https://kernelci.org/build/next/branch/pending-fixes/kernel/v5.2-rc5-413-gd10f6f2d3e41/
Tree: next
Branch: pending-fixes
Git Describe: v5.2-rc5-413-gd10f6f2d3e41
Git Commit: d10f6f2d3e4102b57d7d01d149622ad46c382ff7
Git URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Built: 7 unique architectures
Warnings Detected:
arc:
vdk_hs38_defconfig (gcc-8): 1 warning
vdk_hs38_smp_defconfig (gcc-8): 1 warning
arm64:
allmodconfig (gcc-8): 48 warnings
arm:
integrator_defconfig (gcc-8): 2 warnings
multi_v4t_defconfig (gcc-8): 2 warnings
multi_v5_defconfig (gcc-8): 2 warnings
realview_defconfig (gcc-8): 2 warnings
s3c6400_defconfig (gcc-8): 2 warnings
u300_defconfig (gcc-8): 2 warnings
i386:
mips:
db1xxx_defconfig (gcc-8): 1 warning
malta_qemu_32r6_defconfig (gcc-8): 1 warning
rb532_defconfig (gcc-8): 1 warning
riscv:
rv32_defconfig (gcc-8): 4 warnings
x86_64:
allmodconfig (gcc-8): 51 warnings
tinyconfig (gcc-8): 1 warning
Warnings summary:
10 warning: same module names found:
6 arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end' [-Wunused-variable]
6 arch/arm/mm/init.c:455:13: warning: unused variable 'dtcm_end' [-Wunused-variable]
2 drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c:431:1: warning: the frame size of 4208 bytes is larger than 2048 bytes [-Wframe-larger-than=]
2 drivers/media/dvb-frontends/stv090x.c:3419:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
2 drivers/media/dvb-frontends/stv090x.c:2125:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
2 drivers/media/dvb-frontends/stv0367.c:1902:1: warning: the frame size of 3296 bytes is larger than 2048 bytes [-Wframe-larger-than=]
2 drivers/media/dvb-frontends/cxd2841er.c:3630:1: warning: the frame size of 2784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
2 drivers/gpu/drm/tinydrm/ili9225.c:289:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=]
2 arch/arc/kernel/unwind.c:187:14: warning: 'unw_hdr_alloc' defined but not used [-Wunused-function]
2 <stdin>:830:2: warning: #warning syscall fstat64 not implemented [-Wcpp]
2 <stdin>:1127:2: warning: #warning syscall fstatat64 not implemented [-Wcpp]
1 {standard input}:131: Warning: macro instruction expanded into multiple instructions
1 net/wireless/nl80211.c:6473:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:6473:1: warning: the frame size of 2112 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:5109:1: warning: the frame size of 2784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:5109:1: warning: the frame size of 2776 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:2360:1: warning: the frame size of 4640 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:2360:1: warning: the frame size of 4592 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:1729:1: warning: the frame size of 2280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/wireless/nl80211.c:1729:1: warning: the frame size of 2272 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/ieee802154/nl802154.c:548:1: warning: the frame size of 2256 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/ieee802154/nl802154.c:548:1: warning: the frame size of 2224 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/caif/cfctrl.c:549:1: warning: the frame size of 2608 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/caif/cfctrl.c:549:1: warning: the frame size of 2512 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/bridge/br_netlink.c:1505:1: warning: the frame size of 2696 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 net/bridge/br_netlink.c:1505:1: warning: the frame size of 2688 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 lib/ubsan.o: warning: objtool: ubsan_type_mismatch_common()+0x59: call to stackleak_track_stack() with UACCESS enabled
1 fs/ocfs2/xattr.c:3678:1: warning: the frame size of 2352 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/xattr.c:3678:1: warning: the frame size of 2224 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/super.c:1204:1: warning: the frame size of 3376 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/super.c:1204:1: warning: the frame size of 3368 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/namei.c:2050:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/namei.c:1677:1: warning: the frame size of 2616 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/namei.c:1677:1: warning: the frame size of 2592 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/dlm/dlmrecovery.c:737:1: warning: the frame size of 2112 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/dlm/dlmrecovery.c:737:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/dir.c:3080:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/aops.c:1892:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/ocfs2/aops.c:1892:1: warning: the frame size of 2112 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 fs/btrfs/props.c:389:4: warning: 'num_bytes' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 drivers/staging/rtl8723bs/hal/HalBtc8723b2Ant.c:2924:1: warning: the frame size of 2792 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/staging/rtl8723bs/hal/HalBtc8723b2Ant.c:2924:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/wireless/ralink/rt2x00/rt73usb.c:1283:1: warning: the frame size of 2656 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/wireless/ralink/rt2x00/rt2500usb.c:880:1: warning: the frame size of 2472 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26034:1: warning: the frame size of 2528 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26034:1: warning: the frame size of 2440 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: warning: the frame size of 3136 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: warning: the frame size of 3128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: warning: the frame size of 3168 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: warning: the frame size of 3152 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/ethernet/rocker/rocker_ofdpa.c:559:1: warning: the frame size of 2360 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/net/ethernet/rocker/rocker_ofdpa.c:559:1: warning: the frame size of 2352 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/mtd/nand/raw/au1550nd.c:447:57: warning: pointer type mismatch in conditional expression
1 drivers/media/tuners/r820t.c:1327:1: warning: the frame size of 2848 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/tuners/r820t.c:1327:1: warning: the frame size of 2840 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/pci/saa7134/saa7134-cards.c:8074:1: warning: the frame size of 2144 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/pci/saa7134/saa7134-cards.c:8074:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/i2c/tvp5150.c:253:1: warning: the frame size of 3968 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/i2c/tvp5150.c:253:1: warning: the frame size of 3952 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/i2c/mt9t112.c:480:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:4568:1: warning: the frame size of 2104 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:4568:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:4253:1: warning: the frame size of 2808 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:4253:1: warning: the frame size of 2784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:3078:1: warning: the frame size of 5888 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:3078:1: warning: the frame size of 5880 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:2496:1: warning: the frame size of 2328 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:2496:1: warning: the frame size of 2320 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:2057:1: warning: the frame size of 2576 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:2057:1: warning: the frame size of 2568 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1940:1: warning: the frame size of 3288 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1940:1: warning: the frame size of 3280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1842:1: warning: the frame size of 3016 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1842:1: warning: the frame size of 3008 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1583:1: warning: the frame size of 5320 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1583:1: warning: the frame size of 5312 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1195:1: warning: the frame size of 2088 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1195:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1152:1: warning: the frame size of 2088 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1152:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1111:1: warning: the frame size of 2088 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/stv090x.c:1111:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/cxd2841er.c:3123:1: warning: the frame size of 2736 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/media/dvb-frontends/cxd2841er.c:3123:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/hwtracing/intel_th/msu.c:863:6: warning: unused variable 'i' [-Wunused-variable]
1 drivers/hwtracing/intel_th/msu.c:783:21: warning: unused variable 'i' [-Wunused-variable]
1 drivers/gpu/drm/panel/panel-sitronix-st7701.c:198:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/gpu/drm/panel/panel-sitronix-st7701.c:198:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 drivers/ata/pata_rb532_cf.c:165:24: warning: unused variable 'info' [-Wunused-variable]
1 arch/x86/kvm/x86.c:4299:1: warning: the frame size of 2168 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 arch/x86/kernel/cpu/mshyperv.c:340:1: warning: the frame size of 2856 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 .config:1167:warning: override: UNWINDER_GUESS changes choice state
================================================================================
Detailed per-defconfig build reports:
--------------------------------------------------------------------------------
32r2el_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
32r2el_defconfig+kselftest (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
acs5k_tiny_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allmodconfig (x86_64, gcc-8) — PASS, 0 errors, 51 warnings, 0 section mismatches
Warnings:
arch/x86/kernel/cpu/mshyperv.c:340:1: warning: the frame size of 2856 bytes is larger than 2048 bytes [-Wframe-larger-than=]
arch/x86/kvm/x86.c:4299:1: warning: the frame size of 2168 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/dlm/dlmrecovery.c:737:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/aops.c:1892:1: warning: the frame size of 2112 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/dir.c:3080:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/namei.c:1677:1: warning: the frame size of 2616 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/super.c:1204:1: warning: the frame size of 3368 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/xattr.c:3678:1: warning: the frame size of 2224 bytes is larger than 2048 bytes [-Wframe-larger-than=]
lib/ubsan.o: warning: objtool: ubsan_type_mismatch_common()+0x59: call to stackleak_track_stack() with UACCESS enabled
net/caif/cfctrl.c:549:1: warning: the frame size of 2608 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1505:1: warning: the frame size of 2696 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/ieee802154/nl802154.c:548:1: warning: the frame size of 2224 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/panel/panel-sitronix-st7701.c:198:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/tinydrm/ili9225.c:289:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1729:1: warning: the frame size of 2280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:6473:1: warning: the frame size of 2112 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:2360:1: warning: the frame size of 4592 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:5109:1: warning: the frame size of 2776 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/i2c/tvp5150.c:253:1: warning: the frame size of 3952 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1842:1: warning: the frame size of 3016 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:2125:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:2496:1: warning: the frame size of 2328 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4568:1: warning: the frame size of 2104 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1940:1: warning: the frame size of 3288 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1583:1: warning: the frame size of 5320 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1111:1: warning: the frame size of 2088 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1195:1: warning: the frame size of 2088 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4253:1: warning: the frame size of 2808 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1152:1: warning: the frame size of 2088 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:2057:1: warning: the frame size of 2568 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3078:1: warning: the frame size of 5880 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3419:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv0367.c:1902:1: warning: the frame size of 3296 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3123:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3630:1: warning: the frame size of 2784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/pci/saa7134/saa7134-cards.c:8074:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/tuners/r820t.c:1327:1: warning: the frame size of 2840 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/ethernet/rocker/rocker_ofdpa.c:559:1: warning: the frame size of 2360 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: warning: the frame size of 3152 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: warning: the frame size of 3128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26034:1: warning: the frame size of 2440 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/staging/rtl8723bs/hal/HalBtc8723b2Ant.c:2924:1: warning: the frame size of 2792 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c:431:1: warning: the frame size of 4208 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt2500usb.c:880:1: warning: the frame size of 2472 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/ralink/rt2x00/rt73usb.c:1283:1: warning: the frame size of 2656 bytes is larger than 2048 bytes [-Wframe-larger-than=]
warning: same module names found:
warning: same module names found:
warning: same module names found:
warning: same module names found:
warning: same module names found:
warning: same module names found:
--------------------------------------------------------------------------------
allmodconfig (arm64, gcc-8) — PASS, 0 errors, 48 warnings, 0 section mismatches
Warnings:
fs/btrfs/props.c:389:4: warning: 'num_bytes' may be used uninitialized in this function [-Wmaybe-uninitialized]
fs/ocfs2/dlm/dlmrecovery.c:737:1: warning: the frame size of 2112 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/aops.c:1892:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/namei.c:2050:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/namei.c:1677:1: warning: the frame size of 2592 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/super.c:1204:1: warning: the frame size of 3376 bytes is larger than 2048 bytes [-Wframe-larger-than=]
fs/ocfs2/xattr.c:3678:1: warning: the frame size of 2352 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/bridge/br_netlink.c:1505:1: warning: the frame size of 2688 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/caif/cfctrl.c:549:1: warning: the frame size of 2512 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/ieee802154/nl802154.c:548:1: warning: the frame size of 2256 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/hwtracing/intel_th/msu.c:783:21: warning: unused variable 'i' [-Wunused-variable]
drivers/hwtracing/intel_th/msu.c:863:6: warning: unused variable 'i' [-Wunused-variable]
drivers/gpu/drm/panel/panel-sitronix-st7701.c:198:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/gpu/drm/tinydrm/ili9225.c:289:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:1729:1: warning: the frame size of 2272 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:6473:1: warning: the frame size of 2128 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:2360:1: warning: the frame size of 4640 bytes is larger than 2048 bytes [-Wframe-larger-than=]
net/wireless/nl80211.c:5109:1: warning: the frame size of 2784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/i2c/tvp5150.c:253:1: warning: the frame size of 3968 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1842:1: warning: the frame size of 3008 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:2125:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:2496:1: warning: the frame size of 2320 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4568:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1940:1: warning: the frame size of 3280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1583:1: warning: the frame size of 5312 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1111:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1195:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:4253:1: warning: the frame size of 2784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:1152:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:2057:1: warning: the frame size of 2576 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3078:1: warning: the frame size of 5888 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv090x.c:3419:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/stv0367.c:1902:1: warning: the frame size of 3296 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3123:1: warning: the frame size of 2736 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/dvb-frontends/cxd2841er.c:3630:1: warning: the frame size of 2784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/i2c/mt9t112.c:480:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/pci/saa7134/saa7134-cards.c:8074:1: warning: the frame size of 2144 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/media/tuners/r820t.c:1327:1: warning: the frame size of 2848 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/ethernet/rocker/rocker_ofdpa.c:559:1: warning: the frame size of 2352 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16563:1: warning: the frame size of 3168 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:16905:1: warning: the frame size of 3136 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:26034:1: warning: the frame size of 2528 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/net/wireless/realtek/rtl818x/rtl8180/rtl8225se.c:431:1: warning: the frame size of 4208 bytes is larger than 2048 bytes [-Wframe-larger-than=]
drivers/staging/rtl8723bs/hal/HalBtc8723b2Ant.c:2924:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=]
warning: same module names found:
warning: same module names found:
warning: same module names found:
warning: same module names found:
--------------------------------------------------------------------------------
allnoconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (i386, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
allnoconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
am200epdkit_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ar7_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g4_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
assabet_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
at91_dt_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath25_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ath79_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axm55xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
axs103_smp_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
badge4_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm2835_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm47xx_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bcm63xx_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bigsur_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_be_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
bmips_stb_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
capcella_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cavium_octeon_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cerfcube_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ci20_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
clps711x_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x2xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cm_x300_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cns3420vb_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
cobalt_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa270_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
colibri_pxa300_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
collie_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
corgi_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
davinci_all_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
db1xxx_defconfig (mips, gcc-8) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/mtd/nand/raw/au1550nd.c:447:57: warning: pointer type mismatch in conditional expression
--------------------------------------------------------------------------------
decstation_64_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
decstation_r4k_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+CONFIG_CPU_BIG_ENDIAN=y (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+CONFIG_RANDOMIZE_BASE=y (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+kselftest (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
defconfig+kselftest (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
dove_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
e55_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ebsa110_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
efm32_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
em_x270_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ep93xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
eseries_pxa_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
exynos_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ezx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
footbridge_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
fuloong2e_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gcw0_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gemini_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
gpr_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h3600_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
h5000_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hackkit_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
haps_hs_smp_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hisi_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
hsdk_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig (i386, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
i386_defconfig+kselftest (i386, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imote2_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v4_v5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
imx_v6_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
integrator_defconfig (arm, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end' [-Wunused-variable]
arch/arm/mm/init.c:455:13: warning: unused variable 'dtcm_end' [-Wunused-variable]
--------------------------------------------------------------------------------
iop13xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop32x_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
iop33x_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip22_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip27_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip28_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ip32_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ixp4xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jazz_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jmr3927_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
jornada720_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
keystone_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
ks8695_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lart_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lasat_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lemote2f_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1b_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson1c_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
loongson3_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc18xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpc32xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lpd270_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
lubbock_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
magician_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mainstone_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_kvm_guest_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
malta_qemu_32r6_defconfig (mips, gcc-8) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
{standard input}:131: Warning: macro instruction expanded into multiple instructions
--------------------------------------------------------------------------------
maltaaprp_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltasmvp_eva_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
maltaup_xpa_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
markeins_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
milbeaut_m10v_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mini2440_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mips_paravirt_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mmp2_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
moxart_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mpc30x_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mps2_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
msp71xx_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mtx1_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v4t_defconfig (arm, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end' [-Wunused-variable]
arch/arm/mm/init.c:455:13: warning: unused variable 'dtcm_end' [-Wunused-variable]
--------------------------------------------------------------------------------
multi_v5_defconfig (arm, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end' [-Wunused-variable]
arch/arm/mm/init.c:455:13: warning: unused variable 'dtcm_end' [-Wunused-variable]
--------------------------------------------------------------------------------
multi_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig+CONFIG_SMP=n (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
multi_v7_defconfig+kselftest (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mv78xx0_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mvebu_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
mxs_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
neponset_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netwinder_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
netx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nhk8815_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlp_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nlm_xlr_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_defconfig+kselftest (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsim_hs_smp_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nsimosci_hs_smp_defconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc910_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc950_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
nuc960_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omap1_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omap2plus_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
omega2p_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
orion5x_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
oxnas_v6_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
palmz72_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pcm027_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pic32mzda_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pistachio_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pleb_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pnx8335_stb225_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
prima2_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa168_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa255-idp_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa3xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa910_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
pxa_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qcom_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
qi_lb60_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rb532_defconfig (mips, gcc-8) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
drivers/ata/pata_rb532_cf.c:165:24: warning: unused variable 'info' [-Wunused-variable]
--------------------------------------------------------------------------------
rbtx49xx_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
realview_defconfig (arm, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end' [-Wunused-variable]
arch/arm/mm/init.c:455:13: warning: unused variable 'dtcm_end' [-Wunused-variable]
--------------------------------------------------------------------------------
rm200_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rpc_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rt305x_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
rv32_defconfig (riscv, gcc-8) — PASS, 0 errors, 4 warnings, 0 section mismatches
Warnings:
<stdin>:830:2: warning: #warning syscall fstat64 not implemented [-Wcpp]
<stdin>:1127:2: warning: #warning syscall fstatat64 not implemented [-Wcpp]
<stdin>:830:2: warning: #warning syscall fstat64 not implemented [-Wcpp]
<stdin>:1127:2: warning: #warning syscall fstatat64 not implemented [-Wcpp]
--------------------------------------------------------------------------------
s3c2410_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
s3c6400_defconfig (arm, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end' [-Wunused-variable]
arch/arm/mm/init.c:455:13: warning: unused variable 'dtcm_end' [-Wunused-variable]
--------------------------------------------------------------------------------
s5pv210_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sama5_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sb1250_swarm_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shannon_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
shmobile_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
simpad_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
socfpga_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear13xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear3xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spear6xx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
spitz_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
stm32_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
sunxi_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tango4_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0219_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0226_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tb0287_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tct_hammer_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tegra_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (i386, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (arm64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (x86_64, gcc-8) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
.config:1167:warning: override: UNWINDER_GUESS changes choice state
--------------------------------------------------------------------------------
tinyconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (riscv, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
tinyconfig (arc, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
trizeps4_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
u300_defconfig (arm, gcc-8) — PASS, 0 errors, 2 warnings, 0 section mismatches
Warnings:
arch/arm/mm/init.c:456:13: warning: unused variable 'itcm_end' [-Wunused-variable]
arch/arm/mm/init.c:455:13: warning: unused variable 'dtcm_end' [-Wunused-variable]
--------------------------------------------------------------------------------
u8500_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vdk_hs38_defconfig (arc, gcc-8) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
arch/arc/kernel/unwind.c:187:14: warning: 'unw_hdr_alloc' defined but not used [-Wunused-function]
--------------------------------------------------------------------------------
vdk_hs38_smp_defconfig (arc, gcc-8) — PASS, 0 errors, 1 warning, 0 section mismatches
Warnings:
arch/arc/kernel/unwind.c:187:14: warning: 'unw_hdr_alloc' defined but not used [-Wunused-function]
--------------------------------------------------------------------------------
versatile_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vexpress_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vf610m4_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
viper_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vocore2_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
vt8500_v6_v7_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
workpad_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
x86_64_defconfig+kselftest (x86_64, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
xcep_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
xway_defconfig (mips, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zeus_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
--------------------------------------------------------------------------------
zx_defconfig (arm, gcc-8) — PASS, 0 errors, 0 warnings, 0 section mismatches
---
For more info write to <info@kernelci.org>
^ permalink raw reply
* [PATCH] mtd/ubi: fix initialization order of ubi subsystems
From: Mikhail Kshevetskiy @ 2019-06-20 13:27 UTC (permalink / raw)
To: Artem Bityutskiy; +Cc: linux-mtd
during ubi initialization we have a following calling sequence
1) ubi_attach()
----------------------------------------------------------------
err = ubi_wl_init(ubi, ai);
if (err) goto out_vtbl;
err = ubi_eba_init(ubi, ai);
if (err) goto out_wl;
----------------------------------------------------------------
As we can see "eba" subsytem is NOT initialized at the moment of
initializing of "wl" subsystem
2) ubi_wl_init()
it call ensure_wear_leveling() at some moment
3) ensure_wear_leveling()
---------------------------------------------------------------
e1 = rb_entry(rb_first(&ubi->used), struct ubi_wl_entry, u.rb);
e2 = find_wl_entry(ubi, &ubi->free, WL_FREE_MAX_DIFF);
if (!(e2->ec - e1->ec >= UBI_WL_THRESHOLD)) goto out_unlock;
dbg_wl("schedule wear-leveling");
---------------------------------------------------------------
so, if no wear-leveling is scheduled than everything is OK
and a little bit below
---------------------------------------------------------------
wrk->anchor = 0;
wrk->func = &wear_leveling_worker;
if (nested) __schedule_ubi_work(ubi, wrk);
else schedule_ubi_work(ubi, wrk);
---------------------------------------------------------------
as result we enter to wear_leveling_worker() function
4) wear_leveling_worker()
---------------------------------------------------------------
/*
* Now pick the least worn-out used physical eraseblock and a
* highly worn-out free physical eraseblock. If the erase
* counters differ much enough, start wear-leveling.
*/
e1 = rb_entry(rb_first(&ubi->used), struct ubi_wl_entry, u.rb);
e2 = get_peb_for_wl(ubi);
if (!e2) goto out_cancel;
if (!(e2->ec - e1->ec >= UBI_WL_THRESHOLD)) {
dbg_wl("no WL needed: min used EC %d, max free EC %d", e1->ec, e2->ec);
/* Give the unused PEB back */
wl_tree_add(e2, &ubi->free);
ubi->free_count++;
goto out_cancel;
}
---------------------------------------------------------------
so, if no WL needed than everything is OK
and a little bit below
---------------------------------------------------------------
err = ubi_eba_copy_leb(ubi, e1->pnum, e2->pnum, vid_hdr);
---------------------------------------------------------------
OPS, eba sybsystem is not initialized yet (see (1))
From the other side, it looks like eba sybsystem does not require wl sybsystem
during initialization, so just fix ordering and proper handle error path.
---
drivers/mtd/ubi/attach.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c
index 10b2459f8951..8c1d629c0e1d 100644
--- a/drivers/mtd/ubi/attach.c
+++ b/drivers/mtd/ubi/attach.c
@@ -1602,13 +1602,13 @@ int ubi_attach(struct ubi_device *ubi, int force_scan)
if (err)
goto out_ai;
- err = ubi_wl_init(ubi, ai);
+ err = ubi_eba_init(ubi, ai);
if (err)
goto out_vtbl;
- err = ubi_eba_init(ubi, ai);
+ err = ubi_wl_init(ubi, ai);
if (err)
- goto out_wl;
+ goto out_vtbl;
#ifdef CONFIG_MTD_UBI_FASTMAP
if (ubi->fm && ubi_dbg_chk_fastmap(ubi)) {
--
2.20.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related
* [PATCH][net-next] hinic: fix dereference of pointer hwdev before it is null checked
From: Colin King @ 2019-06-20 13:27 UTC (permalink / raw)
To: Xue Chaojing, Aviad Krawczyk, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently pointer hwdev is dereferenced when assigning hwif before
hwdev is null checked. Fix this by only derefencing hwdev after the
null check.
Addresses-Coverity: ("Dereference before null check")
Fixes: 4fdc51bb4e92 ("hinic: add support for rss parameters with ethtool")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
.../net/ethernet/huawei/hinic/hinic_port.c | 21 +++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_port.c b/drivers/net/ethernet/huawei/hinic/hinic_port.c
index 6b933962de46..1c3b3c0d6298 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_port.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_port.c
@@ -711,14 +711,17 @@ int hinic_get_rss_type(struct hinic_dev *nic_dev, u32 tmpl_idx,
{
struct hinic_rss_context_table ctx_tbl = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(ctx_tbl);
int err;
if (!hwdev || !rss_type)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
ctx_tbl.func_id = HINIC_HWIF_FUNC_IDX(hwif);
ctx_tbl.template_id = tmpl_idx;
@@ -776,14 +779,17 @@ int hinic_rss_get_template_tbl(struct hinic_dev *nic_dev, u32 tmpl_idx,
{
struct hinic_rss_template_key temp_key = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(temp_key);
int err;
if (!hwdev || !temp)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
temp_key.func_id = HINIC_HWIF_FUNC_IDX(hwif);
temp_key.template_id = tmpl_idx;
@@ -832,14 +838,17 @@ int hinic_rss_get_hash_engine(struct hinic_dev *nic_dev, u8 tmpl_idx, u8 *type)
{
struct hinic_rss_engine_type hash_type = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(hash_type);
int err;
if (!hwdev || !type)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
hash_type.func_id = HINIC_HWIF_FUNC_IDX(hwif);
hash_type.template_id = tmpl_idx;
--
2.20.1
^ permalink raw reply related
* [PATCH][net-next] hinic: fix dereference of pointer hwdev before it is null checked
From: Colin King @ 2019-06-20 13:27 UTC (permalink / raw)
To: Xue Chaojing, Aviad Krawczyk, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently pointer hwdev is dereferenced when assigning hwif before
hwdev is null checked. Fix this by only derefencing hwdev after the
null check.
Addresses-Coverity: ("Dereference before null check")
Fixes: 4fdc51bb4e92 ("hinic: add support for rss parameters with ethtool")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
.../net/ethernet/huawei/hinic/hinic_port.c | 21 +++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_port.c b/drivers/net/ethernet/huawei/hinic/hinic_port.c
index 6b933962de46..1c3b3c0d6298 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_port.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_port.c
@@ -711,14 +711,17 @@ int hinic_get_rss_type(struct hinic_dev *nic_dev, u32 tmpl_idx,
{
struct hinic_rss_context_table ctx_tbl = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(ctx_tbl);
int err;
if (!hwdev || !rss_type)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
ctx_tbl.func_id = HINIC_HWIF_FUNC_IDX(hwif);
ctx_tbl.template_id = tmpl_idx;
@@ -776,14 +779,17 @@ int hinic_rss_get_template_tbl(struct hinic_dev *nic_dev, u32 tmpl_idx,
{
struct hinic_rss_template_key temp_key = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(temp_key);
int err;
if (!hwdev || !temp)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
temp_key.func_id = HINIC_HWIF_FUNC_IDX(hwif);
temp_key.template_id = tmpl_idx;
@@ -832,14 +838,17 @@ int hinic_rss_get_hash_engine(struct hinic_dev *nic_dev, u8 tmpl_idx, u8 *type)
{
struct hinic_rss_engine_type hash_type = { 0 };
struct hinic_hwdev *hwdev = nic_dev->hwdev;
- struct hinic_hwif *hwif = hwdev->hwif;
- struct pci_dev *pdev = hwif->pdev;
+ struct hinic_hwif *hwif;
+ struct pci_dev *pdev;
u16 out_size = sizeof(hash_type);
int err;
if (!hwdev || !type)
return -EINVAL;
+ hwif = hwdev->hwif;
+ pdev = hwif->pdev;
+
hash_type.func_id = HINIC_HWIF_FUNC_IDX(hwif);
hash_type.template_id = tmpl_idx;
--
2.20.1
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v10] ssh: switch from libssh2 to libssh
From: Max Reitz @ 2019-06-20 13:01 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: kwolf, fam, qemu-block, rjones, sw, qemu-devel, Pino Toscano,
alex.bennee, philmd
In-Reply-To: <20190620101113.GV25448@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 7486 bytes --]
On 20.06.19 12:11, Daniel P. Berrangé wrote:
> On Tue, Jun 18, 2019 at 03:14:30PM +0200, Max Reitz wrote:
>> On 18.06.19 11:24, Pino Toscano wrote:
>>> Rewrite the implementation of the ssh block driver to use libssh instead
>>> of libssh2. The libssh library has various advantages over libssh2:
>>> - easier API for authentication (for example for using ssh-agent)
>>> - easier API for known_hosts handling
>>> - supports newer types of keys in known_hosts
>>>
>>> Use APIs/features available in libssh 0.8 conditionally, to support
>>> older versions (which are not recommended though).
>>>
>>> Adjust the tests according to the different error message, and to the
>>> newer host keys (ed25519) that are used by default with OpenSSH >= 6.7
>>> and libssh >= 0.7.0.
>>>
>>> Adjust the various Docker/Travis scripts to use libssh when available
>>> instead of libssh2. The mingw/mxe testing is dropped for now, as there
>>> are no packages for it.
>>>
>>> Signed-off-by: Pino Toscano <ptoscano@redhat.com>
>>> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> Acked-by: Alex Bennée <alex.bennee@linaro.org>
>>> ---
>>>
>>> Changes from v9:
>>> - restored "default" case in the server status switch for libssh < 0.8.0
>>> - print the host key type & fingerprint on mismatch with known_hosts
>>> - improve/fix message for failed socket_set_nodelay()
>>> - reset s->sock properly
>>>
>>> Changes from v8:
>>> - use a newer key type in iotest 207
>>> - improve the commit message
>>>
>>> Changes from v7:
>>> - #if HAVE_LIBSSH_0_8 -> #ifdef HAVE_LIBSSH_0_8
>>> - ptrdiff_t -> size_t
>>>
>>> Changes from v6:
>>> - fixed few checkpatch style issues
>>> - detect libssh 0.8 via symbol detection
>>> - adjust travis/docker test material
>>> - remove dead "default" case in a switch
>>> - use variables for storing MIN() results
>>> - adapt a documentation bit
>>>
>>> Changes from v5:
>>> - adapt to newer tracing APIs
>>> - disable ssh compression (mimic what libssh2 does by default)
>>> - use build time checks for libssh 0.8, and use newer APIs directly
>>>
>>> Changes from v4:
>>> - fix wrong usages of error_setg/session_error_setg/sftp_error_setg
>>> - fix few return code checks
>>> - remove now-unused parameters in few internal functions
>>> - allow authentication with "none" method
>>> - switch to unsigned int for the port number
>>> - enable TCP_NODELAY on the socket
>>> - fix one reference error message in iotest 207
>>>
>>> Changes from v3:
>>> - fix socket cleanup in connect_to_ssh()
>>> - add comments about the socket cleanup
>>> - improve the error reporting (closer to what was with libssh2)
>>> - improve EOF detection on sftp_read()
>>>
>>> Changes from v2:
>>> - used again an own fd
>>> - fixed co_yield() implementation
>>>
>>> Changes from v1:
>>> - fixed jumbo packets writing
>>> - fixed missing 'err' assignment
>>> - fixed commit message
>>>
>>> .travis.yml | 4 +-
>>> block/Makefile.objs | 6 +-
>>> block/ssh.c | 665 ++++++++++--------
>>> block/trace-events | 14 +-
>>> configure | 65 +-
>>> docs/qemu-block-drivers.texi | 2 +-
>>> .../dockerfiles/debian-win32-cross.docker | 1 -
>>> .../dockerfiles/debian-win64-cross.docker | 1 -
>>> tests/docker/dockerfiles/fedora.docker | 4 +-
>>> tests/docker/dockerfiles/ubuntu.docker | 2 +-
>>> tests/docker/dockerfiles/ubuntu1804.docker | 2 +-
>>> tests/qemu-iotests/207 | 4 +-
>>> tests/qemu-iotests/207.out | 2 +-
>>> 13 files changed, 423 insertions(+), 349 deletions(-)
>>
>> [...]
>>
>>> diff --git a/block/ssh.c b/block/ssh.c
>>> index 6da7b9cbfe..644ae8b82c 100644
>>> --- a/block/ssh.c
>>> +++ b/block/ssh.c
>>
>> [...]
>>
>>> + case SSH_SERVER_KNOWN_CHANGED:
>>> + ret = -EINVAL;
>>> + r = ssh_get_publickey(s->session, &pubkey);
>>> + if (r == 0) {
>>> + r = ssh_get_publickey_hash(pubkey, SSH_PUBLICKEY_HASH_SHA1,
>>> + &server_hash, &server_hash_len);
>>> + pubkey_type = ssh_key_type(pubkey);
>>> + ssh_key_free(pubkey);
>>> + }
>>> + if (r == 0) {
>>> + fingerprint = ssh_get_fingerprint_hash(SSH_PUBLICKEY_HASH_SHA1,
>>> + server_hash,
>>> + server_hash_len);
>>> + ssh_clean_pubkey_hash(&server_hash);
>>> + }
>>> + if (fingerprint) {
>>> + error_setg(errp,
>>> + "host key (%s key with fingerprint %s) does not match "
>>> + "the one in known_hosts",
>>> + ssh_key_type_to_char(pubkey_type), fingerprint);
>>> + ssh_string_free_char(fingerprint);
>>> + } else {
>>> + error_setg(errp, "host key does not match the one in known_hosts");
>>> + }
>>
>> Usually I’d say that more information can’t be bad. But here I don’t
>> see how this additional information is useful. known_hosts contains
>> base64-encoded full public keys. This only prints the SHA-1 digest.
>> The user cannot add that to known_hosts, or easily scan known_hosts to
>> see whether it perhaps belongs to some other hosts (maybe because DHCP
>> scrambled something).
>>
>> Actually, even if this printed the base64 representation of the full
>> key, the user probably wouldn’t just add that to known_hosts or do
>> anything with it. They’ll debug the problem with other tools.
>>
>> So I don’t think this new information is really useful...?
>>
>>
>> (Hmm, I don’t know if this is a response to my “But the specification
>> requires a warning!!1!”, but if so, I was actually not referring to more
>> information but to this:
>>
>> $ ssh 192.168.0.12
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>> Someone could be eavesdropping on you right now (man-in-the-middle attack)!
>> It is also possible that a host key has just been changed.
>>
>>
>> I mean, I was also only half-serious. I should be serious because the
>> libssh specification requires us to print some warning like that, but,
>> well. Yes, I’ll stop mumbling about this stuff now.)
>
> Those giant messages are targetted at humans though so I'm not so
> convinced it is useful for apps managing QEMU. IMHO it is sufficient
> to just report a simple error that the host ident check failed as
> the patch does now. It gives enough info to then investigate further
> to identify the root cause problems.
I fully agree that that message is absolutely unsuitable for qemu. I
didn’t state that, which is my mistake, sorry.
The point I wanted to make is that I’m citing something that doesn’t
print any data, but just an attack warning. I’d be content with just a
single sentence to that effect (and please not in caps lock), like “It
is possible that someone is attempting a man-in-the-middle attack.”
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [ANNOUNCE] New release rt-tests-1.4
From: John Kacur @ 2019-06-20 13:26 UTC (permalink / raw)
To: Linux RT Users, linux-kernel; +Cc: Clark Williams
We haven't had a release in a while as people were content to work from
git. However, in order to make it easier to use, test, and put into
distributions, now would be a good time for an official release.
There have been a number of interesting changes since 1.3
I'm happy with the way the removal of the --numa from cyclictest is
working now. What this means is that numa is dectected automatically, so
you don't have to specify it. You can still force smp with --smp though.
In addition, cpu affinity should work correctly now. Historically there
were combinations of options in which you couldn't specify cpu affinity,
but these restrictions have been removed.
We have added a number of new programs to the rt-tests suite
- queuelat
- cyclicdeadline
- deadline_test
- ssdd
queuelat simulates a network queue checking for latency violations in
packet processing.
deadline_test is used to test the deadline scheduler (SCHED_DEADLINE)
cyclicdeadline also tests the deadline scheduler in a cyclictest manner
ssdd has a tracer do a bunch of PTRACE_SINGLESTEPs
There is a new feature that adds a duration option to many of the tests
as a more natural way that iterations to determine how long to test for.
There have also been a number of fix and updates, such as an update.
hwlatdetect no-longer requires a kernel module, instead it uses ftrace.
It also works with python3
CPU counters with SMI counter support has been updated, although I think
we're due for another. Hint to Daniel :)
So the latest stable / unstable branch (yes the naming is confusing, and
this will be changed in the future too) is
unstable/devel/latest
If you just to want to use or test the latest then use that
Development for the above is happening here
unstable/devel/latest-devel
This already has some new patches for the deadline tests
This is what developers should development against until
I merge it back into the latest.
Bug reports and patches, are all welcome.
I'd like to step up development, especially bug fixes, and
harden this up. Everything is working reasonably well, but
I'm sure with everyone working the code we can flush out some bugs
and aim for a new stable branch.
So, have fun, and send in your patches and reports!
John Kacur
Clone
git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
branches
Branches
unstable/devel/latest (rt-tests: Version 1.4)
unstable/devel/latest-devel (for latest development of Version 1.4)
tarballs are available here
https://kernel.org/pub/linux/utils/rt-tests/
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v3] ipsec: include high order bytes of esn in pkt len
From: Akhil Goyal @ 2019-06-20 13:25 UTC (permalink / raw)
To: Ananyev, Konstantin, Lukasz Bartosik; +Cc: dev@dpdk.org, anoobj@marvell.com
In-Reply-To: <2601191342CEEE43887BDE71AB97725801688E12CF@IRSMSX104.ger.corp.intel.com>
> >
> > When esn is used then high-order 32 bits are included in ICV
> > calculation however are not transmitted. Update packet length
> > to be consistent with auth data offset and length before crypto
> > operation. High-order 32 bits of esn will be removed from packet
> > length in crypto post processing.
> >
> > Signed-off-by: Lukasz Bartosik <lbartosik@marvell.com>
> > ---
>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
^ permalink raw reply
* Re: [PATCH RFC 4/7] serial: imx: set_termios(): do not enable autoRTS if RTS is unset
From: Sergey Organov @ 2019-06-20 13:24 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-arm-kernel, Uwe Kleine-König, NXP Linux Team,
Pengutronix Kernel Team, linux-serial
In-Reply-To: <20190620093741.7wom6a475be2byob@pengutronix.de>
Hi Sasha,
Sascha Hauer <s.hauer@pengutronix.de> writes:
> Hi Sergey,
>
> On Fri, Jun 14, 2019 at 03:11:31PM +0300, Sergey Organov wrote:
>> set_termios() shouldn't set UCR2_CTSC bit if UCR2_CTS (=TIOCM_RTS) is
>> cleared. Added corresponding check in imx_uart_rts_auto() to fix this.
>>
>> Signed-off-by: Sergey Organov <sorganov@gmail.com>
>> ---
>> drivers/tty/serial/imx.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> index 17e2322..8ee910f 100644
>> --- a/drivers/tty/serial/imx.c
>> +++ b/drivers/tty/serial/imx.c
>> @@ -405,7 +405,8 @@ static void imx_uart_rts_inactive(struct imx_port *sport, u32 *ucr2)
>> /* called with port.lock taken and irqs caller dependent */
>> static void imx_uart_rts_auto(struct imx_port *sport, u32 *ucr2)
>> {
>> - *ucr2 |= UCR2_CTSC;
>> + if (*ucr2 & UCR2_CTS)
>> + *ucr2 |= UCR2_CTSC;
>> }
>
> *ucr2 is set like this in imx_uart_set_termios():
>
> ucr2 = UCR2_SRST | UCR2_IRTS;
> if ((termios->c_cflag & CSIZE) == CS8)
> ucr2 |= UCR2_WS;
> ...
> imx_uart_rts_auto(sport, &ucr2);
>
> So the UCR2_CTS bit is never set, hence UCR2_CTSC will never be set.
> You meant to pass in the actual register value of the UCR2 register.
>
> This is shifted around a bit in the following patches, as an end result
> we have:
>
> old_ucr2 = imx_uart_readl(sport, UCR2);
> ucr2 = old_ucr2 & (UCR2_TXEN | UCR2_RXEN | UCR2_ATEN | UCR2_CTSC);
This is rather the typo problem in my patches right here: it should have
been:
> ucr2 = old_ucr2 & (UCR2_TXEN | UCR2_RXEN | UCR2_ATEN | UCR2_CTS);
as we need to preserve RTS bit state USR2_CTS, not hardware handshake bit
UCR2_CCTS.
> ...
> if (ucr2 & UCR2_CTS)
> ucr2 |= UCR2_CTSC;
>
> Again the test can never be true, it should probably be if (old_ucr2 &
> UCR2_CTS).
No, I believe it's different mistake on my part, see above.
>
> With this issue and the one Lothar has found fixed this series works for
> me.
>
> With these issues fixed I'd be happy to test this series and apply it in
> favour of my patch.
Thanks a lot for reviewing and volunteering to test! It's even more
appreciated as I can't easily test either on recent kernels and/or
without heavy patching of the kernel, and patching would diminish
applicability of my test results to mainstream kernel.
I think I'll better re-roll the series with these 2 corrections, right?
-- Sergey.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] timekeeping: get_jiffies_boot_64() for jiffies that include sleep time
From: Jason A. Donenfeld @ 2019-06-20 13:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linux Kernel Mailing List, Thomas Gleixner, Peter Zijlstra,
Andrew Morton
In-Reply-To: <CAK8P3a2oLUKjY+3Qki59ruygzSb1Vsaoo5Et3BecGzpG8-=tOA@mail.gmail.com>
On Wed, Jun 19, 2019 at 10:57 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wed, Jun 19, 2019 at 10:07 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >
> > On Wed, Jun 19, 2019 at 10:02 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > get_jiffies_boot_64 26
> > > > ktime_get_coarse_boottime 26
> > > > ktime_get_boot_fast_ns with tsc 70
> > > > ktime_get_boot_fast_ns with hpet 4922
> > > > ktime_get_boot_fast_ns with acpi_pm 1884
> > > >
> > > > As expected, hpet is really quite painful.
> > >
> > > I would prefer not to add the new interface then. We might in
> > > fact move users of get_jiffies_64() to ktime_get_coarse() for
> > > consistency given the small overhead of that function.
> >
> > In light of the measurements, that seems like a good plan to me.
> >
> > One thing to consider with moving jiffies users over that way is
> > ktime_t. Do you want to introduce helpers like
> > ktime_get_boot_coarse_ns(), just like there is already with the other
> > various functions like ktime_get_boot_ns(), ktime_get_boot_fast_ns(),
> > etc? (I'd personally prefer using the _ns variants, at least.) I can
> > send a patch for this.
>
> That sounds reasonable, but then I think we should have the full
> set of coarse_*_ns() functions, again for consistency:
>
> u64 ktime_get_coarse_ns(void)
> u64 ktime_get_coarse_boottime_ns(void)
> u64 ktime_get_coarse_real_ns(void)
> u64 ktime_get_coarse_clocktai_ns(void)
>
> and document them in Documentation/core-api/timekeeping.rst.
>
> We seem to also be lacking the basic ktime_get_coarse(), which
> seems like a major omission.
> Both ktime_get_coarse_ns and ktime_get_coarse can be wrappers
> around ktime_get_coarse_ts64() then, while the others would
> use ktime_get_coarse_with_offset().
Exactly what I had in mind. I'll have something posted fairly soon.
Jason
^ permalink raw reply
* [LTP] [PATCH v5 0/4] syscalls/fanotify: FAN_REPORT_FID and Directory Modification Events
From: Petr Vorel @ 2019-06-20 13:24 UTC (permalink / raw)
To: ltp
In-Reply-To: <cover.1561018312.git.mbobrowski@mbobrowski.org>
Hi Amir, Matthew,
LGTM. Just one of this commits fails on centos 6
https://api.travis-ci.org/v3/job/548162141/log.txt
https://travis-ci.org/pevik/ltp/jobs/548162141
gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -D_FORTIFY_SOURCE=2 -I/usr/src/ltp/include -I/usr/src/ltp/../ltp-build/include -I/usr/src/ltp/include/old/ -L/usr/src/ltp/../ltp-build/lib /usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify01.c -lltp -o fanotify01
gcc -g -O2 -g -O2 -fno-strict-aliasing -pipe -Wall -W -Wold-style-definition -D_FORTIFY_SOURCE=2 -I/usr/src/ltp/include -I/usr/src/ltp/../ltp-build/include -I/usr/src/ltp/include/old/ -L/usr/src/ltp/../ltp-build/lib /usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify02.c -lltp -o fanotify02
In file included from /usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify01.c:21:
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:130: error: expected specifier-qualifier-list before '__kernel_fsid_t'
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:141: error: expected declaration specifiers or '...' before '__kernel_fsid_t'
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:142: warning: 'struct file_handle' declared inside parameter list
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:142: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h: In function 'fanotify_get_fid':
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:150: error: 'fsid' undeclared (first use in this function)
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:150: error: (Each undeclared identifier is reported only once
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:150: error: for each function it appears in.)
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:144: warning: unused variable 'mount_id'
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:142: warning: unused parameter 'handle'
In file included from /usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify02.c:21:
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:130: error: expected specifier-qualifier-list before '__kernel_fsid_t'
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:141: error: expected declaration specifiers or '...' before '__kernel_fsid_t'
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:142: warning: 'struct file_handle' declared inside parameter list
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:142: warning: its scope is only this definition or declaration, which is probably not what you want
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h: In function 'fanotify_get_fid':
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:150: error: 'fsid' undeclared (first use in this function)
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:150: error: (Each undeclared identifier is reported only once
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:150: error: for each function it appears in.)
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:144: warning: unused variable 'mount_id'
/usr/src/ltp/testcases/kernel/syscalls/fanotify/fanotify.h:142: warning: unused parameter 'handle'
Kind regards,
Petr
> This patch series contains the changes needed to validate the new
> FAN_REPORT_FID flag and directory modification event functionality
> within the fanotify API.
> Changes since version 4:
> * Fixed problems with unbalanced file descriptor close.
> * Reorded functions in the test files fanotify13, fanotify14 and
> fanotify15 so that they all follow a basic template i.e.
> test()
> ...
> do_setup()
> do_cleanup()
> Thank you Amir for your feedback.
> Amir Goldstein (1):
> syscalls/fanotify13: add test coverage for fsid cache bug
> Matthew Bobrowski (3):
> syscalls/fanotify13: new test to verify FAN_REPORT_FID functionality
> syscalls/fanotify14: new test to validate FAN_REPORT_FID interface
> return values
> syscalls/fanotify15: verify fid for dirent events
> configure.ac | 1 +
> runtest/syscalls | 3 +
> testcases/kernel/syscalls/fanotify/.gitignore | 3 +
> testcases/kernel/syscalls/fanotify/fanotify.h | 81 +++++-
> testcases/kernel/syscalls/fanotify/fanotify05.c | 1 +
> testcases/kernel/syscalls/fanotify/fanotify13.c | 328 ++++++++++++++++++++++++
> testcases/kernel/syscalls/fanotify/fanotify14.c | 176 +++++++++++++
> testcases/kernel/syscalls/fanotify/fanotify15.c | 246 ++++++++++++++++++
> 8 files changed, 836 insertions(+), 3 deletions(-)
> create mode 100644 testcases/kernel/syscalls/fanotify/fanotify13.c
> create mode 100644 testcases/kernel/syscalls/fanotify/fanotify14.c
> create mode 100644 testcases/kernel/syscalls/fanotify/fanotify15.c
^ permalink raw reply
* Re: [PATCH RFC 4/7] serial: imx: set_termios(): do not enable autoRTS if RTS is unset
From: Sergey Organov @ 2019-06-20 13:24 UTC (permalink / raw)
To: Sascha Hauer
Cc: linux-arm-kernel, Uwe Kleine-König, NXP Linux Team,
Pengutronix Kernel Team, linux-serial
In-Reply-To: <20190620093741.7wom6a475be2byob@pengutronix.de>
Hi Sasha,
Sascha Hauer <s.hauer@pengutronix.de> writes:
> Hi Sergey,
>
> On Fri, Jun 14, 2019 at 03:11:31PM +0300, Sergey Organov wrote:
>> set_termios() shouldn't set UCR2_CTSC bit if UCR2_CTS (=TIOCM_RTS) is
>> cleared. Added corresponding check in imx_uart_rts_auto() to fix this.
>>
>> Signed-off-by: Sergey Organov <sorganov@gmail.com>
>> ---
>> drivers/tty/serial/imx.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
>> index 17e2322..8ee910f 100644
>> --- a/drivers/tty/serial/imx.c
>> +++ b/drivers/tty/serial/imx.c
>> @@ -405,7 +405,8 @@ static void imx_uart_rts_inactive(struct imx_port *sport, u32 *ucr2)
>> /* called with port.lock taken and irqs caller dependent */
>> static void imx_uart_rts_auto(struct imx_port *sport, u32 *ucr2)
>> {
>> - *ucr2 |= UCR2_CTSC;
>> + if (*ucr2 & UCR2_CTS)
>> + *ucr2 |= UCR2_CTSC;
>> }
>
> *ucr2 is set like this in imx_uart_set_termios():
>
> ucr2 = UCR2_SRST | UCR2_IRTS;
> if ((termios->c_cflag & CSIZE) == CS8)
> ucr2 |= UCR2_WS;
> ...
> imx_uart_rts_auto(sport, &ucr2);
>
> So the UCR2_CTS bit is never set, hence UCR2_CTSC will never be set.
> You meant to pass in the actual register value of the UCR2 register.
>
> This is shifted around a bit in the following patches, as an end result
> we have:
>
> old_ucr2 = imx_uart_readl(sport, UCR2);
> ucr2 = old_ucr2 & (UCR2_TXEN | UCR2_RXEN | UCR2_ATEN | UCR2_CTSC);
This is rather the typo problem in my patches right here: it should have
been:
> ucr2 = old_ucr2 & (UCR2_TXEN | UCR2_RXEN | UCR2_ATEN | UCR2_CTS);
as we need to preserve RTS bit state USR2_CTS, not hardware handshake bit
UCR2_CCTS.
> ...
> if (ucr2 & UCR2_CTS)
> ucr2 |= UCR2_CTSC;
>
> Again the test can never be true, it should probably be if (old_ucr2 &
> UCR2_CTS).
No, I believe it's different mistake on my part, see above.
>
> With this issue and the one Lothar has found fixed this series works for
> me.
>
> With these issues fixed I'd be happy to test this series and apply it in
> favour of my patch.
Thanks a lot for reviewing and volunteering to test! It's even more
appreciated as I can't easily test either on recent kernels and/or
without heavy patching of the kernel, and patching would diminish
applicability of my test results to mainstream kernel.
I think I'll better re-roll the series with these 2 corrections, right?
-- Sergey.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] memory: do not do out of bound notification
From: Paolo Bonzini @ 2019-06-20 13:14 UTC (permalink / raw)
To: Peter Xu; +Cc: Auger Eric, Yan Zhao, qemu-devel
In-Reply-To: <20190620125955.GB9657@xz-x1>
On 20/06/19 14:59, Peter Xu wrote:
> I feel like this can be problematic. I'm imaging:
>
> start=0x1000_0000, size=0x1000_1000
>
> This will get size=0x1000 but actually we can do size=0x1000_0000 as
> the first.
Right, we can do:
/*
* If a naturally aligned region starting at "start" ends before "end",
* use it. Otherwise, keep the lowest bit of size.
*/
if (size > (start & -start))
size = start & -start;
else
size = size & -size;
>>
>> + trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
>> + VTD_PCI_SLOT(as->devfn),
>> + VTD_PCI_FUNC(as->devfn),
>> + entry.iova, size);
>
> Can move this out because this is a trace only so we don't have
> restriction on mask?
>
>>
>> - map.iova = entry.iova;
>> - map.size = entry.addr_mask;
>> - iova_tree_remove(as->iova_tree, &map);
>> + map.iova = entry.iova;
>> + map.size = entry.addr_mask;
>> + iova_tree_remove(as->iova_tree, &map);
>
> Same here?
>
Yes, I would move these and the iova_tree_remove outside the loop, while
keeping entry's initialization inside looks cleaner.
Paolo
^ permalink raw reply
* Re: [PATCH 1/7] video: add HDMI state notifier support
From: Cheng-yi Chiang @ 2019-06-20 13:23 UTC (permalink / raw)
To: Cheng-yi Chiang, Hans Verkuil, linux-kernel,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Philipp Zabel,
Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Russell King, Andrzej Hajda, Laurent Pinchart, David Airlie,
Rob Herring, Heiko Stuebner, Doug Anderson, Dylan Reid, tzungbi,
linux-media,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
dri-devel, linux-arm-kernel, linux-rockchip, devicetree,
Dariusz Marcinkiewicz
Cc: Daniel Vetter
In-Reply-To: <20190620092506.GP12905@phenom.ffwll.local>
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > > > > > > > > > From: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > >
> > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > > > > > > > > > information from HDMI drivers to their CEC and audio counterparts.
> > > > > > > > > > >
> > > > > > > > > > > Based on an earlier version from Russell King:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/
> > > > > > > > > > >
> > > > > > > > > > > The hdmi_notifier is a reference counted object containing the HDMI state
> > > > > > > > > > > of an HDMI device.
> > > > > > > > > > >
> > > > > > > > > > > When a new notifier is registered the current state will be reported to
> > > > > > > > > > > that notifier at registration time.
> > > > > > > > > > >
> > > > > > > > > > > Based on Hans Verkuil's patch:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/
> > > > > > > > > >
> > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific notifier
> > > > > > > > > > found in drivers/media/cec/cec-notifier.c?
> > > > > > > > > >
> > > > > > > > > > I don't think it makes sense to have two notifier implementations in the kernel.
> > > > > > > > > > The original intention was to have the notifier deal with both CEC and ASoC
> > > > > > > > > > notifications, but there was not enough interest for the ASoC bits at the time
> > > > > > > > > > and it was dropped.
> > > > > > > > > >
> > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on that this
> > > > > > > > > > week. I'll CC you when I post those. Those might be a good starting point
> > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally intended.
> > > > > > > > > >
> > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
> > > > > > > > > > working on some nice cec-notifier improvements as well.
> > > > > > > > >
> > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi
> > > > > > > > > already in drm/drm_audio_component.h, but it's not used by anything
> > > > > > > > > outside of i915. Imo we should extend that, not reinvent a new wheel.
> > > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it is
> > > > > > > > specific to HDA.
> > > > > > > > I am not familiar with drm and HDA. I am not sure how applicable it
> > > > > > > > would be to report jack status to ASoC.
> > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
> > > > > > > > should be possible.
> > > > > > >
> > > > > > > Currently hda is the only user, but the idea was to make it more generic.
> > > > > > > Jack status in alsa is what drm calls connector status btw.
> > > > > > >
> > > > > > > So if we can take that as a baseline and extend it (probably needs some
> > > > > > > registration boilerplate and helpers to look up the right endpoint using
> > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), that
> > > > > > > would be great I think.
> > > > > > >
> > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for one
> > > > > > > > > case, as soon as you have multiple devices and need to make sure you get
> > > > > > > > > the update for the right one it all comes crashing down. Please create an
> > > > > > > > > api which registers for updates from a specific device only, plus
> > > > > > > > > something that has real callbacks (like the drm_audio_component.h thing we
> > > > > > > > > started already).
> > > > > > > >
> > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a
> > > > > > > > specific device only.
> > > > > > > > hdmi_notifier_get takes a device and return the notifier.
> > > > > > >
> > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier
> > > > > > > concerns addressed.
> > > > > > >
> > > > > > > > It seems that a major difference between drm_audio_components and
> > > > > > > > hdmi-notifier is that
> > > > > > > > drm_audio_components defines all supported ops in drm_audio_component_audio_ops.
> > > > > > > > On the other hand, hdmi-notifier passes different events using an enum
> > > > > > > > like HDMI_CONNECTED and let listener handle different events.
> > > > > > > > In this regard I agree with you that drm_audio_component is cleaner.
> > > > > > > > Anyway, I will look into it a bit more and see how it works.
> > > > > > >
> > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for
> > > > > > > registration, some _ops structure for the actual notifications, then
> > > > > > > there's a solid interface. I just really don't like the opaque void *
> > > > > > > interface notifier provides, it encourages abuse way too much.
> > > > > > >
> > > > > > > Ofc the registration side would then no longer be based on the notifier
> > > > > > > datastructure, list_head (like cec-notifier.c) of registeres devices with
> > > > > > > their _ops structure should be enough.
> > > > > > > -Daniel
> > > > > >
> > > > > > Hi Daniel,
> > > > > > Yes, I agree the above statement that we should have a more solid interface.
> > > > > >
> > > > > > Hi Hans,
> > > > > > I am not sure if I missed the patch.
> > > > > > Do you have a estimated timeline for new cec-notifier interface you
> > > > > > are working on?
> > > > > > It seems that your PoC patch needs Dariusz's patch to work.
> > > > > > I would like to seek your advice on whether I can proceed without your
> > > > > > patch and Dariusz's patch.
> > > > > >
> > > > > > I looked through the patch from Dariusz
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/21/389
> > > > > >
> > > > > > , and saw that you were thinking whether we should use cec-notifier
> > > > > > for both HDMI and CEC.
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/24/298
> > > > > >
> > > > > > Could you please let me know your latest thought on whether we should
> > > > > > reuse cec-notifier?
> > > > >
> > > > > Nah, see later in that thread, I think cec and audio seem to be different
> > > > > use-cases.
> > > > >
> > > > Ack
> > > > > But definitely a good idea to sync with Dariusz, I forgot to pull the two
> > > > > threads together. Thanks for doing that.
> > > > >
> > > > > > I agree with you that I should not proceed with hdmi-notifier. Reasons include:
> > > > > > 1. Method like cec_notifier_parse_hdmi_phandle can be reused. It is
> > > > > > error prone to memory leak if it is implemented by user, like the
> > > > > > patch in hdmi-codec.c in this series did not handle the ref count.
> > > > > > 2. cec-notifier has a simpler implementation of register / unregister
> > > > > > because there is no call chain. I am not aware of the need for
> > > > > > hdmi-notifier to support a chain of callbacks. So I think that call
> > > > > > chain support can be removed.
> > > > > >
> > > > > > If I go ahead and add a new interface to register ops to handle
> > > > > > connector status report from cec-notifer, based on current
> > > > > > cec-notifier, do you think that would work ?
> > > > > > I think it might work if I add another cec_notifier object inside
> > > > > > dw-hdmi.c, but only for HDMI jack reporting, not for CEC related
> > > > > > reporting.
> > > > > >
> > > > > > And after some investigation, I realize that my requirement is even
> > > > > > simpler. I don't need hdmi_event_new_edid and hdmi_event_new_eld in my
> > > > > > use case.
> > > > >
> > > > > Yeah, connector status is how we started with the drm/alsa interface in
> > > > > i915 too, but later on had to extend it. I think eventually we'll need it
> > > > > all, that's why I suggested to use that as the interface between drm and
> > > > > alsa side, but augmented with some register/unregister and bind logic.
> > > > >
> > > > Hi Daniel,
> > > > Sorry for the late reply.
> > > > I spent some time investigating how drm_audio_component works.
> > > > The coupling of HDA in drm_audio_component framework makes the
> > > > register/unregister logic looks complicated to me as I don't use HDA
> > > > in my use case.
> > > > After some time, I found another patch series which also use component
> > > > framework to communicate between drm and mei world.
> > > >
> > > > https://patchwork.kernel.org/patch/10824527/
> > > >
> > > > And from that patch, I realized that I can follow the similar approach
> > > > to register a master component on ALSA side, a slave component on DRM
> > > > side, and use device and subcomponent to match them.
> > >
> > > Sorry for the confusion here. My suggestion is _not_ to use the component
> > > framework. That's only meant for one-off special case solutions. For that
> > > part I think you need to build a new register/unregister/bind/unbind
> > > infrastructure, like we have for lots of other things in the kernel
> > > already (clocks, gpio, drm_panel, drm_bridge as just a few examples).
> > >
> >
> > Hi Daniel,
> > Thank you for the prompt reply and guidance.
> >
> > I see. I was not aware that we should avoid using component framework.
> > Your example of drm_panel seems great.
> > I plan is to reuse drm_audio_components like this:
> > A LIST_HEAD holding the list of drm_audio_components instances, and add API
> > drm_audio_comp_init,
> > _add, _remove, _attach, _detach.
> > And for DRM side to look up the instance to use, we can use similar
> > approach like of_drm_find_panel, that is, using device tree node.
>
> Sounds good. I guess somewhere in there you'll use of_node/DT information
> to make sure you have the right audio component? Just to make sure we're
> agreeing on the design completely.
ACK.
I need to check closer. I will use of_node/DT information,
but it might be the other way around as machine driver can get the
hdmi node and hence hdmi device,
and that device can be passed to codec driver to register a component
with the device.
So the register mechanism is more like original hdmi_notifier.
>
>
> > > My suggestion with the i915/hda interface is to build on the actual
> > > interface for signalling connector status and exchanging eld and stuff
> > > like that.
> > >
> >
> > I agree with using this interface. But in my use case there is no much
> > data to be exchanged.
> > Only the connector status needs to be passed from DRM to ALSA world.
> > If in the future there is need for ALSA to make some call, that ops
> > can be added to drm_audio_component_ops.
>
> Yeah I think it's ok to not implement everyhing. Iirc we started with only
> the connector status too, then extended that to sharing the eld.
>
> There's also some i915/had hacks (clocks without using clock framework,
> power domains without using power framework), where for DT platforms we
> probably want to do this right.
>
> Looking at the entire thing we might need to create new _ops structures,
> or at least refactor them quite a bit. But we can improve things
> iteratively imo.
ACK
>
>
> > > > I should be able to do this without touching anything specific to HDA.
> > > > After that, DRM world should be able to use the ops in
> > > > drm_audio_component_audio_ops to notify ALSA world some event when
> > > > there is something happen in DRM world.
> > > > Currently the ops like pin_eld_notify, pin2port are too specific to HDA.
> > > > I think I can add an ops to drm_audio_component_audio_ops to convey
> > > > connector status.
> > >
> > > Hm why? The pin2port is maybe not the best one, since port is an intel
> > > construct, and pin a hda construct. So we'd need to change those to talk
> > > in terms of the higher-level concepts (alsa output pin and drm crtc
> > > probably).
> > >
> >
> > I took more look into how information of audio being present or not is
> > passed between DRM and ALSA world,
> > taking drivers/gpu/drm/i915/intel_audio.c and
> > sound/soc/codecs/hdac_hdmi.c as example.
> > I see the sequence is DRM side to call pin_eld_notify ops with port
> > and pipe to ALSA side.
> > Then, ALSA side calls get_eld ops with port and pipe to look up
> > whether the saved encoder has audio_connector.
> >
> > However, my use case on RK3288 is different in that ALSA side does not
> > need to get ELD.
> > I think adding an ops like connector_status() for DRM side to call in
> > parallel to pin_eld_notify is reasonable.
> > Both DRM side and ALSA side can choose what is the desired ops to be
> > implemented as these ops can be optional.
>
> I think pin_eld_notify and get_eld are just mislabeled, they give you both
> eld and status (the bool *enabled in get_eld). Maybe we should rename them
> to get_status and pin_status_notify?
ACK
>
> > > The other stuff should work a bit better. Either way my idea was to evolve
> > > that interface (and put in the place the required type-casting for
> > > i915/hda), since more users increases the odds that it actually is a good
> > > design.
> > >
> > Sorry I don't understand this part.
> > Could you please elaborate more about type-casting for i915/hda ?
> >
> > TBH, If possible, I would like to minimize the change I'll need to
> > make to i915/hda because of my limited knowledge of i915/hda and my
> > limited bandwidth.
> >
> > I would like to point out the scope of this problem to help the discussion.
> > I think this is a common need on boards using ALSA hdmi-codec driver.
> > Currently, there are many DRM drivers resorted to hdmi_codec_ops
> > approach to let ALSA world talks to DRM world.
> > That hdmi_codec_ops approach came around 2016 so it was before
> > drm_audio_component was introduced.
> > As for how jack status is reported for these boards, I am not sure,
> > maybe with local patches of hdmi-notifier.
> > So this is not a one-off change for RK3288 only. I believe other
> > boards will benefit from this jack reporting feature as well.
> >
> > As for extending and improving the interface of drm_audio_component so
> > more users can adopt it,
> > I think the ops in hdmi_codec_ops are good candidates to be moved to
> > drm_audio_component to consolidate the interface between DRM and ALSA
> > better.
> > That said, I don't feel a strong need to change i915/hda if the
> > purpose is to let more users use drm_audio_component.
> >
> > I can drew these changes in three stages:
> > 1. Add the infrastructure to add/remove/attach/detach
> > drm_audio_component (like how drm_panel does), and add
> > connector_status ops.
> > 2. Move ops in hdmi_codec_ops into drm_audio_components.
> > 3. Desired change of i915/hda (I am not clear about this part)
> >
> > I can help with 1 and 2 as Chromium tree have at least RK3288 and
> > MT8173 SoC using hdmi-codec driver so it is easier for me to try
> > patches.
> > And there may be more in the future.
> >
> > Thanks again for the patience.
> > I am not familiar with DRM so it takes me more time to digest your
> > comment and reply.
>
> Hm sorry, I totally forgot about this again, iirc I looked at this.
>
> Yeah fully agreeing that hdmi_audio_code is probably a better starting
> point. Problem is that becuase hdmi_codec is built on top of platform
> device it's quite a bit harder to extend with callbacks and things like
> that, without breaking the driver model.
>
> I need to think about this more, but if all we need to look at is
> hdmi_codec, then I think this becomes a lot easier. And we can ignore
> drm_audio_component.h completely.
It is surprising that you think this way.
Maybe the original patch before hdmi-notifier was introduced is the
better way to solve this issue, if we only need to look at hdmi_codec.
The history of hdmi_codec driver is in this patch series:
https://lore.kernel.org/patchwork/patch/539656/
There was a callback mechanism implemented between dw-hdmi and hdmi
codec driver.
It was later consolidated by Doug in this patch for better jack status
reporting:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/
I am not sure why the original patch series did not get fully accepted
in the upstream.
It was quite long time ago.
But if you think this might be the right way to do, then it is even
better for us because the patch series and Doug's patch had been quite
stable
on our RK3288 products for about four years with plenty of users, so
we have much higher confidence in them.
I can rebase and clean up them and post another patch for review.
Please let me know what approach you feel is better.
Thanks again!
>
> -Daniel
>
>
> >
> > > > I will work toward this approach these days.
> > > > If you have other thought please let me know.
> > > > Thanks!
> > > >
> > > > > > I just need to report the connector status from synopsys/dw-hdmi.c to
> > > > > > codecs/hdmi-codec.c for codec driver to update the jack status.
> > > > > > Do you think I can proceed in this direction ? Or do you prefer I wait
> > > > > > for a while and work on it based on your new patch.
> > > > >
> > > > > I think most important part here is that we sync across all the different
> > > > > people pushing for better drm/alsa integration. What the solution looks
> > > > > like in the end doesn't matter much imo, as long as we don't end up with 3
> > > > > different things :-)
> > > >
> > > > Totally agree.
> > >
> > > Anyway just my thoughts, let's keep chatting.
> > >
> > > Cheers, Daniel
> > >
> > > > Thanks again!
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > >
> > > > > > Thanks a lot!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks again!
> > > > > > > >
> > > > > > > > > -Daniel
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Hans
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Modified by Cheng-Yi Chiang:
> > > > > > > > > > > - Add a section in MAINTAINER.
> > > > > > > > > > > - Changes connected and has_eld to bitfield of unsigned int.
> > > > > > > > > > > - Other minor fixes to pass checkpatch.pl --strict checks.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> > > > > > > > > > > ---
> > > > > > > > > > > The original patch is at
> > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverkuil@xs4all.nl
> > > > > > > > > > >
> > > > > > > > > > > MAINTAINERS | 6 ++
> > > > > > > > > > > drivers/video/Kconfig | 3 +
> > > > > > > > > > > drivers/video/Makefile | 1 +
> > > > > > > > > > > drivers/video/hdmi-notifier.c | 145 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > include/linux/hdmi-notifier.h | 112 ++++++++++++++++++++++++++
> > > > > > > > > > > 5 files changed, 267 insertions(+)
> > > > > > > > > > > create mode 100644 drivers/video/hdmi-notifier.c
> > > > > > > > > > > create mode 100644 include/linux/hdmi-notifier.h
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > > > > > > > index 5cfbea4ce575..ffb7376f9509 100644
> > > > > > > > > > > --- a/MAINTAINERS
> > > > > > > > > > > +++ b/MAINTAINERS
> > > > > > > > > > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> > > > > > > > > > > S: Maintained
> > > > > > > > > > > F: drivers/media/platform/vicodec/*
> > > > > > > > > > >
> > > > > > > > > > > +VIDEO FRAMEWORK
> > > > > > > > > > > +M: Hans Verkuil <hverkuil@xs4all.nl>
> > > > > > > > > > > +L: linux-media@vger.kernel.org
> > > > > > > > > > > +F: drivers/video/hdmi-notifier.*
> > > > > > > > > > > +S: Maintained
> > > > > > > > > > > +
> > > > > > > > > > > VIDEO MULTIPLEXER DRIVER
> > > > > > > > > > > M: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > L: linux-media@vger.kernel.org
> > > > > > > > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > > > > > > > > index 83d3d271ca15..000ba9bc0ae7 100644
> > > > > > > > > > > --- a/drivers/video/Kconfig
> > > > > > > > > > > +++ b/drivers/video/Kconfig
> > > > > > > > > > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> > > > > > > > > > > config HDMI
> > > > > > > > > > > bool
> > > > > > > > > > >
> > > > > > > > > > > +config HDMI_NOTIFIERS
> > > > > > > > > > > + bool
> > > > > > > > > > > +
> > > > > > > > > > > endif # HAS_IOMEM
> > > > > > > > > > >
> > > > > > > > > > > if VT
> > > > > > > > > > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > > > > > > > > > index df7650adede9..eff4736102ca 100644
> > > > > > > > > > > --- a/drivers/video/Makefile
> > > > > > > > > > > +++ b/drivers/video/Makefile
> > > > > > > > > > > @@ -1,6 +1,7 @@
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > obj-$(CONFIG_VGASTATE) += vgastate.o
> > > > > > > > > > > obj-$(CONFIG_HDMI) += hdmi.o
> > > > > > > > > > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_VT) += console/
> > > > > > > > > > > obj-$(CONFIG_FB_STI) += console/
> > > > > > > > > > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..d1eedf661648
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > @@ -0,0 +1,145 @@
> > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/export.h>
> > > > > > > > > > > +#include <linux/hdmi-notifier.h>
> > > > > > > > > > > +#include <linux/string.h>
> > > > > > > > > > > +#include <linux/slab.h>
> > > > > > > > > > > +#include <linux/list.h>
> > > > > > > > > > > +
> > > > > > > > > > > +static LIST_HEAD(hdmi_notifiers);
> > > > > > > > > > > +static DEFINE_MUTEX(hdmi_notifiers_lock);
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n;
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_for_each_entry(n, &hdmi_notifiers, head) {
> > > > > > > > > > > + if (n->dev == dev) {
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + return n;
> > > > > > > > > > > + }
> > > > > > > > > > > + }
> > > > > > > > > > > + n = kzalloc(sizeof(*n), GFP_KERNEL);
> > > > > > > > > > > + if (!n)
> > > > > > > > > > > + goto unlock;
> > > > > > > > > > > + n->dev = dev;
> > > > > > > > > > > + mutex_init(&n->lock);
> > > > > > > > > > > + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> > > > > > > > > > > + kref_init(&n->kref);
> > > > > > > > > > > + list_add_tail(&n->head, &hdmi_notifiers);
> > > > > > > > > > > +unlock:
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + return n;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> > > > > > > > > > > +
> > > > > > > > > > > +static void hdmi_notifier_release(struct kref *kref)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n =
> > > > > > > > > > > + container_of(kref, struct hdmi_notifier, kref);
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_del(&n->head);
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + kfree(n);
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + kref_put(&n->kref, hdmi_notifier_release);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->connected) {
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + if (n->edid_size)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_EDID, n);
> > > > > > > > > > > + if (n->has_eld)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_ELD, n);
> > > > > > > > > > > + }
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret == 0)
> > > > > > > > > > > + hdmi_notifier_put(n);
> > > > > > > > > > > + return ret;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = false;
> > > > > > > > > > > + n->has_eld = false;
> > > > > > > > > > > + n->edid_size = 0;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->edid_allocated_size < size) {
> > > > > > > > > > > + void *p = kmalloc(size, GFP_KERNEL);
> > > > > > > > > > > +
> > > > > > > > > > > + if (!p) {
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return -ENOMEM;
> > > > > > > > > > > + }
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + n->edid = p;
> > > > > > > > > > > + n->edid_allocated_size = size;
> > > > > > > > > > > + }
> > > > > > > > > > > + memcpy(n->edid, edid, size);
> > > > > > > > > > > + n->edid_size = size;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128])
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + memcpy(n->eld, eld, sizeof(n->eld));
> > > > > > > > > > > + n->has_eld = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> > > > > > > > > > > diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..c8f35110e3e3
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/include/linux/hdmi-notifier.h
> > > > > > > > > > > @@ -0,0 +1,112 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > + * hdmi-notifier.h - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +#define LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/types.h>
> > > > > > > > > > > +#include <linux/notifier.h>
> > > > > > > > > > > +#include <linux/kref.h>
> > > > > > > > > > > +
> > > > > > > > > > > +enum {
> > > > > > > > > > > + HDMI_CONNECTED,
> > > > > > > > > > > + HDMI_DISCONNECTED,
> > > > > > > > > > > + HDMI_NEW_EDID,
> > > > > > > > > > > + HDMI_NEW_ELD,
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +struct device;
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier {
> > > > > > > > > > > + /* Lock to protect callback registration and notification. */
> > > > > > > > > > > + struct mutex lock;
> > > > > > > > > > > + struct list_head head;
> > > > > > > > > > > + struct kref kref;
> > > > > > > > > > > + struct blocking_notifier_head notifiers;
> > > > > > > > > > > + struct device *dev;
> > > > > > > > > > > +
> > > > > > > > > > > + /* Current state */
> > > > > > > > > > > + unsigned int connected : 1;
> > > > > > > > > > > + unsigned int has_eld : 1;
> > > > > > > > > > > + unsigned char eld[128];
> > > > > > > > > > > + void *edid;
> > > > > > > > > > > + size_t edid_size;
> > > > > > > > > > > + size_t edid_allocated_size;
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_get - find or create a new hdmi_notifier for the given device.
> > > > > > > > > > > + * @dev: device that sends the events.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If a notifier for device @dev already exists, then increase the refcount
> > > > > > > > > > > + * and return that notifier.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If it doesn't exist, then allocate a new notifier struct and return a
> > > > > > > > > > > + * pointer to that new struct.
> > > > > > > > > > > + *
> > > > > > > > > > > + * Return NULL if the memory could not be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_put - decrease refcount and delete when the refcount reaches 0.
> > > > > > > > > > > + * @n: notifier
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_register - register the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_unregister - unregister the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n,
> > > > > > > > > > > + struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_connect - send a connect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_CONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_disconnect - send a disconnect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_DISCONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_edid - send a new EDID event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_EDID event to any registered parties.
> > > > > > > > > > > + * This function will make a copy the EDID so it can return -ENOMEM if
> > > > > > > > > > > + * no memory could be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_eld - send a new ELD event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_ELD event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128]);
> > > > > > > > > > > +
> > > > > > > > > > > +#endif
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Vetter
> > > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > > http://blog.ffwll.ch
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Vetter
> > > > > > > Software Engineer, Intel Corporation
> > > > > > > http://blog.ffwll.ch
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [alsa-devel] [PATCH 1/7] video: add HDMI state notifier support
From: Cheng-yi Chiang @ 2019-06-20 13:23 UTC (permalink / raw)
To: Cheng-yi Chiang, Hans Verkuil, linux-kernel,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Philipp Zabel,
Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Russell King, Andrzej Hajda, Laurent Pinchart, David Airlie,
Rob Herring, Heiko Stuebner, Doug Anderson, Dylan Reid, tzungbi,
linux-media,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
dri-devel, linux-arm-kernel, linux-rockchip, devicetree,
Dariusz Marcinkiewicz
Cc: Daniel Vetter
In-Reply-To: <20190620092506.GP12905@phenom.ffwll.local>
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > > > > > > > > > From: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > >
> > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > > > > > > > > > information from HDMI drivers to their CEC and audio counterparts.
> > > > > > > > > > >
> > > > > > > > > > > Based on an earlier version from Russell King:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/
> > > > > > > > > > >
> > > > > > > > > > > The hdmi_notifier is a reference counted object containing the HDMI state
> > > > > > > > > > > of an HDMI device.
> > > > > > > > > > >
> > > > > > > > > > > When a new notifier is registered the current state will be reported to
> > > > > > > > > > > that notifier at registration time.
> > > > > > > > > > >
> > > > > > > > > > > Based on Hans Verkuil's patch:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/
> > > > > > > > > >
> > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific notifier
> > > > > > > > > > found in drivers/media/cec/cec-notifier.c?
> > > > > > > > > >
> > > > > > > > > > I don't think it makes sense to have two notifier implementations in the kernel.
> > > > > > > > > > The original intention was to have the notifier deal with both CEC and ASoC
> > > > > > > > > > notifications, but there was not enough interest for the ASoC bits at the time
> > > > > > > > > > and it was dropped.
> > > > > > > > > >
> > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on that this
> > > > > > > > > > week. I'll CC you when I post those. Those might be a good starting point
> > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally intended.
> > > > > > > > > >
> > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
> > > > > > > > > > working on some nice cec-notifier improvements as well.
> > > > > > > > >
> > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi
> > > > > > > > > already in drm/drm_audio_component.h, but it's not used by anything
> > > > > > > > > outside of i915. Imo we should extend that, not reinvent a new wheel.
> > > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it is
> > > > > > > > specific to HDA.
> > > > > > > > I am not familiar with drm and HDA. I am not sure how applicable it
> > > > > > > > would be to report jack status to ASoC.
> > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
> > > > > > > > should be possible.
> > > > > > >
> > > > > > > Currently hda is the only user, but the idea was to make it more generic.
> > > > > > > Jack status in alsa is what drm calls connector status btw.
> > > > > > >
> > > > > > > So if we can take that as a baseline and extend it (probably needs some
> > > > > > > registration boilerplate and helpers to look up the right endpoint using
> > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), that
> > > > > > > would be great I think.
> > > > > > >
> > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for one
> > > > > > > > > case, as soon as you have multiple devices and need to make sure you get
> > > > > > > > > the update for the right one it all comes crashing down. Please create an
> > > > > > > > > api which registers for updates from a specific device only, plus
> > > > > > > > > something that has real callbacks (like the drm_audio_component.h thing we
> > > > > > > > > started already).
> > > > > > > >
> > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a
> > > > > > > > specific device only.
> > > > > > > > hdmi_notifier_get takes a device and return the notifier.
> > > > > > >
> > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier
> > > > > > > concerns addressed.
> > > > > > >
> > > > > > > > It seems that a major difference between drm_audio_components and
> > > > > > > > hdmi-notifier is that
> > > > > > > > drm_audio_components defines all supported ops in drm_audio_component_audio_ops.
> > > > > > > > On the other hand, hdmi-notifier passes different events using an enum
> > > > > > > > like HDMI_CONNECTED and let listener handle different events.
> > > > > > > > In this regard I agree with you that drm_audio_component is cleaner.
> > > > > > > > Anyway, I will look into it a bit more and see how it works.
> > > > > > >
> > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for
> > > > > > > registration, some _ops structure for the actual notifications, then
> > > > > > > there's a solid interface. I just really don't like the opaque void *
> > > > > > > interface notifier provides, it encourages abuse way too much.
> > > > > > >
> > > > > > > Ofc the registration side would then no longer be based on the notifier
> > > > > > > datastructure, list_head (like cec-notifier.c) of registeres devices with
> > > > > > > their _ops structure should be enough.
> > > > > > > -Daniel
> > > > > >
> > > > > > Hi Daniel,
> > > > > > Yes, I agree the above statement that we should have a more solid interface.
> > > > > >
> > > > > > Hi Hans,
> > > > > > I am not sure if I missed the patch.
> > > > > > Do you have a estimated timeline for new cec-notifier interface you
> > > > > > are working on?
> > > > > > It seems that your PoC patch needs Dariusz's patch to work.
> > > > > > I would like to seek your advice on whether I can proceed without your
> > > > > > patch and Dariusz's patch.
> > > > > >
> > > > > > I looked through the patch from Dariusz
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/21/389
> > > > > >
> > > > > > , and saw that you were thinking whether we should use cec-notifier
> > > > > > for both HDMI and CEC.
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/24/298
> > > > > >
> > > > > > Could you please let me know your latest thought on whether we should
> > > > > > reuse cec-notifier?
> > > > >
> > > > > Nah, see later in that thread, I think cec and audio seem to be different
> > > > > use-cases.
> > > > >
> > > > Ack
> > > > > But definitely a good idea to sync with Dariusz, I forgot to pull the two
> > > > > threads together. Thanks for doing that.
> > > > >
> > > > > > I agree with you that I should not proceed with hdmi-notifier. Reasons include:
> > > > > > 1. Method like cec_notifier_parse_hdmi_phandle can be reused. It is
> > > > > > error prone to memory leak if it is implemented by user, like the
> > > > > > patch in hdmi-codec.c in this series did not handle the ref count.
> > > > > > 2. cec-notifier has a simpler implementation of register / unregister
> > > > > > because there is no call chain. I am not aware of the need for
> > > > > > hdmi-notifier to support a chain of callbacks. So I think that call
> > > > > > chain support can be removed.
> > > > > >
> > > > > > If I go ahead and add a new interface to register ops to handle
> > > > > > connector status report from cec-notifer, based on current
> > > > > > cec-notifier, do you think that would work ?
> > > > > > I think it might work if I add another cec_notifier object inside
> > > > > > dw-hdmi.c, but only for HDMI jack reporting, not for CEC related
> > > > > > reporting.
> > > > > >
> > > > > > And after some investigation, I realize that my requirement is even
> > > > > > simpler. I don't need hdmi_event_new_edid and hdmi_event_new_eld in my
> > > > > > use case.
> > > > >
> > > > > Yeah, connector status is how we started with the drm/alsa interface in
> > > > > i915 too, but later on had to extend it. I think eventually we'll need it
> > > > > all, that's why I suggested to use that as the interface between drm and
> > > > > alsa side, but augmented with some register/unregister and bind logic.
> > > > >
> > > > Hi Daniel,
> > > > Sorry for the late reply.
> > > > I spent some time investigating how drm_audio_component works.
> > > > The coupling of HDA in drm_audio_component framework makes the
> > > > register/unregister logic looks complicated to me as I don't use HDA
> > > > in my use case.
> > > > After some time, I found another patch series which also use component
> > > > framework to communicate between drm and mei world.
> > > >
> > > > https://patchwork.kernel.org/patch/10824527/
> > > >
> > > > And from that patch, I realized that I can follow the similar approach
> > > > to register a master component on ALSA side, a slave component on DRM
> > > > side, and use device and subcomponent to match them.
> > >
> > > Sorry for the confusion here. My suggestion is _not_ to use the component
> > > framework. That's only meant for one-off special case solutions. For that
> > > part I think you need to build a new register/unregister/bind/unbind
> > > infrastructure, like we have for lots of other things in the kernel
> > > already (clocks, gpio, drm_panel, drm_bridge as just a few examples).
> > >
> >
> > Hi Daniel,
> > Thank you for the prompt reply and guidance.
> >
> > I see. I was not aware that we should avoid using component framework.
> > Your example of drm_panel seems great.
> > I plan is to reuse drm_audio_components like this:
> > A LIST_HEAD holding the list of drm_audio_components instances, and add API
> > drm_audio_comp_init,
> > _add, _remove, _attach, _detach.
> > And for DRM side to look up the instance to use, we can use similar
> > approach like of_drm_find_panel, that is, using device tree node.
>
> Sounds good. I guess somewhere in there you'll use of_node/DT information
> to make sure you have the right audio component? Just to make sure we're
> agreeing on the design completely.
ACK.
I need to check closer. I will use of_node/DT information,
but it might be the other way around as machine driver can get the
hdmi node and hence hdmi device,
and that device can be passed to codec driver to register a component
with the device.
So the register mechanism is more like original hdmi_notifier.
>
>
> > > My suggestion with the i915/hda interface is to build on the actual
> > > interface for signalling connector status and exchanging eld and stuff
> > > like that.
> > >
> >
> > I agree with using this interface. But in my use case there is no much
> > data to be exchanged.
> > Only the connector status needs to be passed from DRM to ALSA world.
> > If in the future there is need for ALSA to make some call, that ops
> > can be added to drm_audio_component_ops.
>
> Yeah I think it's ok to not implement everyhing. Iirc we started with only
> the connector status too, then extended that to sharing the eld.
>
> There's also some i915/had hacks (clocks without using clock framework,
> power domains without using power framework), where for DT platforms we
> probably want to do this right.
>
> Looking at the entire thing we might need to create new _ops structures,
> or at least refactor them quite a bit. But we can improve things
> iteratively imo.
ACK
>
>
> > > > I should be able to do this without touching anything specific to HDA.
> > > > After that, DRM world should be able to use the ops in
> > > > drm_audio_component_audio_ops to notify ALSA world some event when
> > > > there is something happen in DRM world.
> > > > Currently the ops like pin_eld_notify, pin2port are too specific to HDA.
> > > > I think I can add an ops to drm_audio_component_audio_ops to convey
> > > > connector status.
> > >
> > > Hm why? The pin2port is maybe not the best one, since port is an intel
> > > construct, and pin a hda construct. So we'd need to change those to talk
> > > in terms of the higher-level concepts (alsa output pin and drm crtc
> > > probably).
> > >
> >
> > I took more look into how information of audio being present or not is
> > passed between DRM and ALSA world,
> > taking drivers/gpu/drm/i915/intel_audio.c and
> > sound/soc/codecs/hdac_hdmi.c as example.
> > I see the sequence is DRM side to call pin_eld_notify ops with port
> > and pipe to ALSA side.
> > Then, ALSA side calls get_eld ops with port and pipe to look up
> > whether the saved encoder has audio_connector.
> >
> > However, my use case on RK3288 is different in that ALSA side does not
> > need to get ELD.
> > I think adding an ops like connector_status() for DRM side to call in
> > parallel to pin_eld_notify is reasonable.
> > Both DRM side and ALSA side can choose what is the desired ops to be
> > implemented as these ops can be optional.
>
> I think pin_eld_notify and get_eld are just mislabeled, they give you both
> eld and status (the bool *enabled in get_eld). Maybe we should rename them
> to get_status and pin_status_notify?
ACK
>
> > > The other stuff should work a bit better. Either way my idea was to evolve
> > > that interface (and put in the place the required type-casting for
> > > i915/hda), since more users increases the odds that it actually is a good
> > > design.
> > >
> > Sorry I don't understand this part.
> > Could you please elaborate more about type-casting for i915/hda ?
> >
> > TBH, If possible, I would like to minimize the change I'll need to
> > make to i915/hda because of my limited knowledge of i915/hda and my
> > limited bandwidth.
> >
> > I would like to point out the scope of this problem to help the discussion.
> > I think this is a common need on boards using ALSA hdmi-codec driver.
> > Currently, there are many DRM drivers resorted to hdmi_codec_ops
> > approach to let ALSA world talks to DRM world.
> > That hdmi_codec_ops approach came around 2016 so it was before
> > drm_audio_component was introduced.
> > As for how jack status is reported for these boards, I am not sure,
> > maybe with local patches of hdmi-notifier.
> > So this is not a one-off change for RK3288 only. I believe other
> > boards will benefit from this jack reporting feature as well.
> >
> > As for extending and improving the interface of drm_audio_component so
> > more users can adopt it,
> > I think the ops in hdmi_codec_ops are good candidates to be moved to
> > drm_audio_component to consolidate the interface between DRM and ALSA
> > better.
> > That said, I don't feel a strong need to change i915/hda if the
> > purpose is to let more users use drm_audio_component.
> >
> > I can drew these changes in three stages:
> > 1. Add the infrastructure to add/remove/attach/detach
> > drm_audio_component (like how drm_panel does), and add
> > connector_status ops.
> > 2. Move ops in hdmi_codec_ops into drm_audio_components.
> > 3. Desired change of i915/hda (I am not clear about this part)
> >
> > I can help with 1 and 2 as Chromium tree have at least RK3288 and
> > MT8173 SoC using hdmi-codec driver so it is easier for me to try
> > patches.
> > And there may be more in the future.
> >
> > Thanks again for the patience.
> > I am not familiar with DRM so it takes me more time to digest your
> > comment and reply.
>
> Hm sorry, I totally forgot about this again, iirc I looked at this.
>
> Yeah fully agreeing that hdmi_audio_code is probably a better starting
> point. Problem is that becuase hdmi_codec is built on top of platform
> device it's quite a bit harder to extend with callbacks and things like
> that, without breaking the driver model.
>
> I need to think about this more, but if all we need to look at is
> hdmi_codec, then I think this becomes a lot easier. And we can ignore
> drm_audio_component.h completely.
It is surprising that you think this way.
Maybe the original patch before hdmi-notifier was introduced is the
better way to solve this issue, if we only need to look at hdmi_codec.
The history of hdmi_codec driver is in this patch series:
https://lore.kernel.org/patchwork/patch/539656/
There was a callback mechanism implemented between dw-hdmi and hdmi
codec driver.
It was later consolidated by Doug in this patch for better jack status
reporting:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/
I am not sure why the original patch series did not get fully accepted
in the upstream.
It was quite long time ago.
But if you think this might be the right way to do, then it is even
better for us because the patch series and Doug's patch had been quite
stable
on our RK3288 products for about four years with plenty of users, so
we have much higher confidence in them.
I can rebase and clean up them and post another patch for review.
Please let me know what approach you feel is better.
Thanks again!
>
> -Daniel
>
>
> >
> > > > I will work toward this approach these days.
> > > > If you have other thought please let me know.
> > > > Thanks!
> > > >
> > > > > > I just need to report the connector status from synopsys/dw-hdmi.c to
> > > > > > codecs/hdmi-codec.c for codec driver to update the jack status.
> > > > > > Do you think I can proceed in this direction ? Or do you prefer I wait
> > > > > > for a while and work on it based on your new patch.
> > > > >
> > > > > I think most important part here is that we sync across all the different
> > > > > people pushing for better drm/alsa integration. What the solution looks
> > > > > like in the end doesn't matter much imo, as long as we don't end up with 3
> > > > > different things :-)
> > > >
> > > > Totally agree.
> > >
> > > Anyway just my thoughts, let's keep chatting.
> > >
> > > Cheers, Daniel
> > >
> > > > Thanks again!
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > >
> > > > > > Thanks a lot!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks again!
> > > > > > > >
> > > > > > > > > -Daniel
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Hans
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Modified by Cheng-Yi Chiang:
> > > > > > > > > > > - Add a section in MAINTAINER.
> > > > > > > > > > > - Changes connected and has_eld to bitfield of unsigned int.
> > > > > > > > > > > - Other minor fixes to pass checkpatch.pl --strict checks.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> > > > > > > > > > > ---
> > > > > > > > > > > The original patch is at
> > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverkuil@xs4all.nl
> > > > > > > > > > >
> > > > > > > > > > > MAINTAINERS | 6 ++
> > > > > > > > > > > drivers/video/Kconfig | 3 +
> > > > > > > > > > > drivers/video/Makefile | 1 +
> > > > > > > > > > > drivers/video/hdmi-notifier.c | 145 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > include/linux/hdmi-notifier.h | 112 ++++++++++++++++++++++++++
> > > > > > > > > > > 5 files changed, 267 insertions(+)
> > > > > > > > > > > create mode 100644 drivers/video/hdmi-notifier.c
> > > > > > > > > > > create mode 100644 include/linux/hdmi-notifier.h
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > > > > > > > index 5cfbea4ce575..ffb7376f9509 100644
> > > > > > > > > > > --- a/MAINTAINERS
> > > > > > > > > > > +++ b/MAINTAINERS
> > > > > > > > > > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> > > > > > > > > > > S: Maintained
> > > > > > > > > > > F: drivers/media/platform/vicodec/*
> > > > > > > > > > >
> > > > > > > > > > > +VIDEO FRAMEWORK
> > > > > > > > > > > +M: Hans Verkuil <hverkuil@xs4all.nl>
> > > > > > > > > > > +L: linux-media@vger.kernel.org
> > > > > > > > > > > +F: drivers/video/hdmi-notifier.*
> > > > > > > > > > > +S: Maintained
> > > > > > > > > > > +
> > > > > > > > > > > VIDEO MULTIPLEXER DRIVER
> > > > > > > > > > > M: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > L: linux-media@vger.kernel.org
> > > > > > > > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > > > > > > > > index 83d3d271ca15..000ba9bc0ae7 100644
> > > > > > > > > > > --- a/drivers/video/Kconfig
> > > > > > > > > > > +++ b/drivers/video/Kconfig
> > > > > > > > > > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> > > > > > > > > > > config HDMI
> > > > > > > > > > > bool
> > > > > > > > > > >
> > > > > > > > > > > +config HDMI_NOTIFIERS
> > > > > > > > > > > + bool
> > > > > > > > > > > +
> > > > > > > > > > > endif # HAS_IOMEM
> > > > > > > > > > >
> > > > > > > > > > > if VT
> > > > > > > > > > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > > > > > > > > > index df7650adede9..eff4736102ca 100644
> > > > > > > > > > > --- a/drivers/video/Makefile
> > > > > > > > > > > +++ b/drivers/video/Makefile
> > > > > > > > > > > @@ -1,6 +1,7 @@
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > obj-$(CONFIG_VGASTATE) += vgastate.o
> > > > > > > > > > > obj-$(CONFIG_HDMI) += hdmi.o
> > > > > > > > > > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_VT) += console/
> > > > > > > > > > > obj-$(CONFIG_FB_STI) += console/
> > > > > > > > > > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..d1eedf661648
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > @@ -0,0 +1,145 @@
> > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/export.h>
> > > > > > > > > > > +#include <linux/hdmi-notifier.h>
> > > > > > > > > > > +#include <linux/string.h>
> > > > > > > > > > > +#include <linux/slab.h>
> > > > > > > > > > > +#include <linux/list.h>
> > > > > > > > > > > +
> > > > > > > > > > > +static LIST_HEAD(hdmi_notifiers);
> > > > > > > > > > > +static DEFINE_MUTEX(hdmi_notifiers_lock);
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n;
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_for_each_entry(n, &hdmi_notifiers, head) {
> > > > > > > > > > > + if (n->dev == dev) {
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + return n;
> > > > > > > > > > > + }
> > > > > > > > > > > + }
> > > > > > > > > > > + n = kzalloc(sizeof(*n), GFP_KERNEL);
> > > > > > > > > > > + if (!n)
> > > > > > > > > > > + goto unlock;
> > > > > > > > > > > + n->dev = dev;
> > > > > > > > > > > + mutex_init(&n->lock);
> > > > > > > > > > > + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> > > > > > > > > > > + kref_init(&n->kref);
> > > > > > > > > > > + list_add_tail(&n->head, &hdmi_notifiers);
> > > > > > > > > > > +unlock:
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + return n;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> > > > > > > > > > > +
> > > > > > > > > > > +static void hdmi_notifier_release(struct kref *kref)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n =
> > > > > > > > > > > + container_of(kref, struct hdmi_notifier, kref);
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_del(&n->head);
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + kfree(n);
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + kref_put(&n->kref, hdmi_notifier_release);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->connected) {
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + if (n->edid_size)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_EDID, n);
> > > > > > > > > > > + if (n->has_eld)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_ELD, n);
> > > > > > > > > > > + }
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret == 0)
> > > > > > > > > > > + hdmi_notifier_put(n);
> > > > > > > > > > > + return ret;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = false;
> > > > > > > > > > > + n->has_eld = false;
> > > > > > > > > > > + n->edid_size = 0;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->edid_allocated_size < size) {
> > > > > > > > > > > + void *p = kmalloc(size, GFP_KERNEL);
> > > > > > > > > > > +
> > > > > > > > > > > + if (!p) {
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return -ENOMEM;
> > > > > > > > > > > + }
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + n->edid = p;
> > > > > > > > > > > + n->edid_allocated_size = size;
> > > > > > > > > > > + }
> > > > > > > > > > > + memcpy(n->edid, edid, size);
> > > > > > > > > > > + n->edid_size = size;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128])
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + memcpy(n->eld, eld, sizeof(n->eld));
> > > > > > > > > > > + n->has_eld = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> > > > > > > > > > > diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..c8f35110e3e3
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/include/linux/hdmi-notifier.h
> > > > > > > > > > > @@ -0,0 +1,112 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > + * hdmi-notifier.h - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +#define LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/types.h>
> > > > > > > > > > > +#include <linux/notifier.h>
> > > > > > > > > > > +#include <linux/kref.h>
> > > > > > > > > > > +
> > > > > > > > > > > +enum {
> > > > > > > > > > > + HDMI_CONNECTED,
> > > > > > > > > > > + HDMI_DISCONNECTED,
> > > > > > > > > > > + HDMI_NEW_EDID,
> > > > > > > > > > > + HDMI_NEW_ELD,
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +struct device;
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier {
> > > > > > > > > > > + /* Lock to protect callback registration and notification. */
> > > > > > > > > > > + struct mutex lock;
> > > > > > > > > > > + struct list_head head;
> > > > > > > > > > > + struct kref kref;
> > > > > > > > > > > + struct blocking_notifier_head notifiers;
> > > > > > > > > > > + struct device *dev;
> > > > > > > > > > > +
> > > > > > > > > > > + /* Current state */
> > > > > > > > > > > + unsigned int connected : 1;
> > > > > > > > > > > + unsigned int has_eld : 1;
> > > > > > > > > > > + unsigned char eld[128];
> > > > > > > > > > > + void *edid;
> > > > > > > > > > > + size_t edid_size;
> > > > > > > > > > > + size_t edid_allocated_size;
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_get - find or create a new hdmi_notifier for the given device.
> > > > > > > > > > > + * @dev: device that sends the events.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If a notifier for device @dev already exists, then increase the refcount
> > > > > > > > > > > + * and return that notifier.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If it doesn't exist, then allocate a new notifier struct and return a
> > > > > > > > > > > + * pointer to that new struct.
> > > > > > > > > > > + *
> > > > > > > > > > > + * Return NULL if the memory could not be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_put - decrease refcount and delete when the refcount reaches 0.
> > > > > > > > > > > + * @n: notifier
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_register - register the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_unregister - unregister the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n,
> > > > > > > > > > > + struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_connect - send a connect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_CONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_disconnect - send a disconnect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_DISCONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_edid - send a new EDID event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_EDID event to any registered parties.
> > > > > > > > > > > + * This function will make a copy the EDID so it can return -ENOMEM if
> > > > > > > > > > > + * no memory could be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_eld - send a new ELD event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_ELD event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128]);
> > > > > > > > > > > +
> > > > > > > > > > > +#endif
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Vetter
> > > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > > http://blog.ffwll.ch
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Vetter
> > > > > > > Software Engineer, Intel Corporation
> > > > > > > http://blog.ffwll.ch
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH 1/7] video: add HDMI state notifier support
From: Cheng-yi Chiang @ 2019-06-20 13:23 UTC (permalink / raw)
To: Cheng-yi Chiang, Hans Verkuil, linux-kernel,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Philipp Zabel,
Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Russell King, Andrzej Hajda, Laurent Pinchart, David Airlie,
Rob Herring, Heiko Stuebner, Doug Anderson, Dylan Reid, tzungbi,
linux-media,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
dri-devel
Cc: Daniel Vetter
In-Reply-To: <20190620092506.GP12905@phenom.ffwll.local>
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > > > > > > > > > From: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > >
> > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > > > > > > > > > information from HDMI drivers to their CEC and audio counterparts.
> > > > > > > > > > >
> > > > > > > > > > > Based on an earlier version from Russell King:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/
> > > > > > > > > > >
> > > > > > > > > > > The hdmi_notifier is a reference counted object containing the HDMI state
> > > > > > > > > > > of an HDMI device.
> > > > > > > > > > >
> > > > > > > > > > > When a new notifier is registered the current state will be reported to
> > > > > > > > > > > that notifier at registration time.
> > > > > > > > > > >
> > > > > > > > > > > Based on Hans Verkuil's patch:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/
> > > > > > > > > >
> > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific notifier
> > > > > > > > > > found in drivers/media/cec/cec-notifier.c?
> > > > > > > > > >
> > > > > > > > > > I don't think it makes sense to have two notifier implementations in the kernel.
> > > > > > > > > > The original intention was to have the notifier deal with both CEC and ASoC
> > > > > > > > > > notifications, but there was not enough interest for the ASoC bits at the time
> > > > > > > > > > and it was dropped.
> > > > > > > > > >
> > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on that this
> > > > > > > > > > week. I'll CC you when I post those. Those might be a good starting point
> > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally intended.
> > > > > > > > > >
> > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
> > > > > > > > > > working on some nice cec-notifier improvements as well.
> > > > > > > > >
> > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi
> > > > > > > > > already in drm/drm_audio_component.h, but it's not used by anything
> > > > > > > > > outside of i915. Imo we should extend that, not reinvent a new wheel.
> > > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it is
> > > > > > > > specific to HDA.
> > > > > > > > I am not familiar with drm and HDA. I am not sure how applicable it
> > > > > > > > would be to report jack status to ASoC.
> > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
> > > > > > > > should be possible.
> > > > > > >
> > > > > > > Currently hda is the only user, but the idea was to make it more generic.
> > > > > > > Jack status in alsa is what drm calls connector status btw.
> > > > > > >
> > > > > > > So if we can take that as a baseline and extend it (probably needs some
> > > > > > > registration boilerplate and helpers to look up the right endpoint using
> > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), that
> > > > > > > would be great I think.
> > > > > > >
> > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for one
> > > > > > > > > case, as soon as you have multiple devices and need to make sure you get
> > > > > > > > > the update for the right one it all comes crashing down. Please create an
> > > > > > > > > api which registers for updates from a specific device only, plus
> > > > > > > > > something that has real callbacks (like the drm_audio_component.h thing we
> > > > > > > > > started already).
> > > > > > > >
> > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a
> > > > > > > > specific device only.
> > > > > > > > hdmi_notifier_get takes a device and return the notifier.
> > > > > > >
> > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier
> > > > > > > concerns addressed.
> > > > > > >
> > > > > > > > It seems that a major difference between drm_audio_components and
> > > > > > > > hdmi-notifier is that
> > > > > > > > drm_audio_components defines all supported ops in drm_audio_component_audio_ops.
> > > > > > > > On the other hand, hdmi-notifier passes different events using an enum
> > > > > > > > like HDMI_CONNECTED and let listener handle different events.
> > > > > > > > In this regard I agree with you that drm_audio_component is cleaner.
> > > > > > > > Anyway, I will look into it a bit more and see how it works.
> > > > > > >
> > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for
> > > > > > > registration, some _ops structure for the actual notifications, then
> > > > > > > there's a solid interface. I just really don't like the opaque void *
> > > > > > > interface notifier provides, it encourages abuse way too much.
> > > > > > >
> > > > > > > Ofc the registration side would then no longer be based on the notifier
> > > > > > > datastructure, list_head (like cec-notifier.c) of registeres devices with
> > > > > > > their _ops structure should be enough.
> > > > > > > -Daniel
> > > > > >
> > > > > > Hi Daniel,
> > > > > > Yes, I agree the above statement that we should have a more solid interface.
> > > > > >
> > > > > > Hi Hans,
> > > > > > I am not sure if I missed the patch.
> > > > > > Do you have a estimated timeline for new cec-notifier interface you
> > > > > > are working on?
> > > > > > It seems that your PoC patch needs Dariusz's patch to work.
> > > > > > I would like to seek your advice on whether I can proceed without your
> > > > > > patch and Dariusz's patch.
> > > > > >
> > > > > > I looked through the patch from Dariusz
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/21/389
> > > > > >
> > > > > > , and saw that you were thinking whether we should use cec-notifier
> > > > > > for both HDMI and CEC.
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/24/298
> > > > > >
> > > > > > Could you please let me know your latest thought on whether we should
> > > > > > reuse cec-notifier?
> > > > >
> > > > > Nah, see later in that thread, I think cec and audio seem to be different
> > > > > use-cases.
> > > > >
> > > > Ack
> > > > > But definitely a good idea to sync with Dariusz, I forgot to pull the two
> > > > > threads together. Thanks for doing that.
> > > > >
> > > > > > I agree with you that I should not proceed with hdmi-notifier. Reasons include:
> > > > > > 1. Method like cec_notifier_parse_hdmi_phandle can be reused. It is
> > > > > > error prone to memory leak if it is implemented by user, like the
> > > > > > patch in hdmi-codec.c in this series did not handle the ref count.
> > > > > > 2. cec-notifier has a simpler implementation of register / unregister
> > > > > > because there is no call chain. I am not aware of the need for
> > > > > > hdmi-notifier to support a chain of callbacks. So I think that call
> > > > > > chain support can be removed.
> > > > > >
> > > > > > If I go ahead and add a new interface to register ops to handle
> > > > > > connector status report from cec-notifer, based on current
> > > > > > cec-notifier, do you think that would work ?
> > > > > > I think it might work if I add another cec_notifier object inside
> > > > > > dw-hdmi.c, but only for HDMI jack reporting, not for CEC related
> > > > > > reporting.
> > > > > >
> > > > > > And after some investigation, I realize that my requirement is even
> > > > > > simpler. I don't need hdmi_event_new_edid and hdmi_event_new_eld in my
> > > > > > use case.
> > > > >
> > > > > Yeah, connector status is how we started with the drm/alsa interface in
> > > > > i915 too, but later on had to extend it. I think eventually we'll need it
> > > > > all, that's why I suggested to use that as the interface between drm and
> > > > > alsa side, but augmented with some register/unregister and bind logic.
> > > > >
> > > > Hi Daniel,
> > > > Sorry for the late reply.
> > > > I spent some time investigating how drm_audio_component works.
> > > > The coupling of HDA in drm_audio_component framework makes the
> > > > register/unregister logic looks complicated to me as I don't use HDA
> > > > in my use case.
> > > > After some time, I found another patch series which also use component
> > > > framework to communicate between drm and mei world.
> > > >
> > > > https://patchwork.kernel.org/patch/10824527/
> > > >
> > > > And from that patch, I realized that I can follow the similar approach
> > > > to register a master component on ALSA side, a slave component on DRM
> > > > side, and use device and subcomponent to match them.
> > >
> > > Sorry for the confusion here. My suggestion is _not_ to use the component
> > > framework. That's only meant for one-off special case solutions. For that
> > > part I think you need to build a new register/unregister/bind/unbind
> > > infrastructure, like we have for lots of other things in the kernel
> > > already (clocks, gpio, drm_panel, drm_bridge as just a few examples).
> > >
> >
> > Hi Daniel,
> > Thank you for the prompt reply and guidance.
> >
> > I see. I was not aware that we should avoid using component framework.
> > Your example of drm_panel seems great.
> > I plan is to reuse drm_audio_components like this:
> > A LIST_HEAD holding the list of drm_audio_components instances, and add API
> > drm_audio_comp_init,
> > _add, _remove, _attach, _detach.
> > And for DRM side to look up the instance to use, we can use similar
> > approach like of_drm_find_panel, that is, using device tree node.
>
> Sounds good. I guess somewhere in there you'll use of_node/DT information
> to make sure you have the right audio component? Just to make sure we're
> agreeing on the design completely.
ACK.
I need to check closer. I will use of_node/DT information,
but it might be the other way around as machine driver can get the
hdmi node and hence hdmi device,
and that device can be passed to codec driver to register a component
with the device.
So the register mechanism is more like original hdmi_notifier.
>
>
> > > My suggestion with the i915/hda interface is to build on the actual
> > > interface for signalling connector status and exchanging eld and stuff
> > > like that.
> > >
> >
> > I agree with using this interface. But in my use case there is no much
> > data to be exchanged.
> > Only the connector status needs to be passed from DRM to ALSA world.
> > If in the future there is need for ALSA to make some call, that ops
> > can be added to drm_audio_component_ops.
>
> Yeah I think it's ok to not implement everyhing. Iirc we started with only
> the connector status too, then extended that to sharing the eld.
>
> There's also some i915/had hacks (clocks without using clock framework,
> power domains without using power framework), where for DT platforms we
> probably want to do this right.
>
> Looking at the entire thing we might need to create new _ops structures,
> or at least refactor them quite a bit. But we can improve things
> iteratively imo.
ACK
>
>
> > > > I should be able to do this without touching anything specific to HDA.
> > > > After that, DRM world should be able to use the ops in
> > > > drm_audio_component_audio_ops to notify ALSA world some event when
> > > > there is something happen in DRM world.
> > > > Currently the ops like pin_eld_notify, pin2port are too specific to HDA.
> > > > I think I can add an ops to drm_audio_component_audio_ops to convey
> > > > connector status.
> > >
> > > Hm why? The pin2port is maybe not the best one, since port is an intel
> > > construct, and pin a hda construct. So we'd need to change those to talk
> > > in terms of the higher-level concepts (alsa output pin and drm crtc
> > > probably).
> > >
> >
> > I took more look into how information of audio being present or not is
> > passed between DRM and ALSA world,
> > taking drivers/gpu/drm/i915/intel_audio.c and
> > sound/soc/codecs/hdac_hdmi.c as example.
> > I see the sequence is DRM side to call pin_eld_notify ops with port
> > and pipe to ALSA side.
> > Then, ALSA side calls get_eld ops with port and pipe to look up
> > whether the saved encoder has audio_connector.
> >
> > However, my use case on RK3288 is different in that ALSA side does not
> > need to get ELD.
> > I think adding an ops like connector_status() for DRM side to call in
> > parallel to pin_eld_notify is reasonable.
> > Both DRM side and ALSA side can choose what is the desired ops to be
> > implemented as these ops can be optional.
>
> I think pin_eld_notify and get_eld are just mislabeled, they give you both
> eld and status (the bool *enabled in get_eld). Maybe we should rename them
> to get_status and pin_status_notify?
ACK
>
> > > The other stuff should work a bit better. Either way my idea was to evolve
> > > that interface (and put in the place the required type-casting for
> > > i915/hda), since more users increases the odds that it actually is a good
> > > design.
> > >
> > Sorry I don't understand this part.
> > Could you please elaborate more about type-casting for i915/hda ?
> >
> > TBH, If possible, I would like to minimize the change I'll need to
> > make to i915/hda because of my limited knowledge of i915/hda and my
> > limited bandwidth.
> >
> > I would like to point out the scope of this problem to help the discussion.
> > I think this is a common need on boards using ALSA hdmi-codec driver.
> > Currently, there are many DRM drivers resorted to hdmi_codec_ops
> > approach to let ALSA world talks to DRM world.
> > That hdmi_codec_ops approach came around 2016 so it was before
> > drm_audio_component was introduced.
> > As for how jack status is reported for these boards, I am not sure,
> > maybe with local patches of hdmi-notifier.
> > So this is not a one-off change for RK3288 only. I believe other
> > boards will benefit from this jack reporting feature as well.
> >
> > As for extending and improving the interface of drm_audio_component so
> > more users can adopt it,
> > I think the ops in hdmi_codec_ops are good candidates to be moved to
> > drm_audio_component to consolidate the interface between DRM and ALSA
> > better.
> > That said, I don't feel a strong need to change i915/hda if the
> > purpose is to let more users use drm_audio_component.
> >
> > I can drew these changes in three stages:
> > 1. Add the infrastructure to add/remove/attach/detach
> > drm_audio_component (like how drm_panel does), and add
> > connector_status ops.
> > 2. Move ops in hdmi_codec_ops into drm_audio_components.
> > 3. Desired change of i915/hda (I am not clear about this part)
> >
> > I can help with 1 and 2 as Chromium tree have at least RK3288 and
> > MT8173 SoC using hdmi-codec driver so it is easier for me to try
> > patches.
> > And there may be more in the future.
> >
> > Thanks again for the patience.
> > I am not familiar with DRM so it takes me more time to digest your
> > comment and reply.
>
> Hm sorry, I totally forgot about this again, iirc I looked at this.
>
> Yeah fully agreeing that hdmi_audio_code is probably a better starting
> point. Problem is that becuase hdmi_codec is built on top of platform
> device it's quite a bit harder to extend with callbacks and things like
> that, without breaking the driver model.
>
> I need to think about this more, but if all we need to look at is
> hdmi_codec, then I think this becomes a lot easier. And we can ignore
> drm_audio_component.h completely.
It is surprising that you think this way.
Maybe the original patch before hdmi-notifier was introduced is the
better way to solve this issue, if we only need to look at hdmi_codec.
The history of hdmi_codec driver is in this patch series:
https://lore.kernel.org/patchwork/patch/539656/
There was a callback mechanism implemented between dw-hdmi and hdmi
codec driver.
It was later consolidated by Doug in this patch for better jack status
reporting:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/
I am not sure why the original patch series did not get fully accepted
in the upstream.
It was quite long time ago.
But if you think this might be the right way to do, then it is even
better for us because the patch series and Doug's patch had been quite
stable
on our RK3288 products for about four years with plenty of users, so
we have much higher confidence in them.
I can rebase and clean up them and post another patch for review.
Please let me know what approach you feel is better.
Thanks again!
>
> -Daniel
>
>
> >
> > > > I will work toward this approach these days.
> > > > If you have other thought please let me know.
> > > > Thanks!
> > > >
> > > > > > I just need to report the connector status from synopsys/dw-hdmi.c to
> > > > > > codecs/hdmi-codec.c for codec driver to update the jack status.
> > > > > > Do you think I can proceed in this direction ? Or do you prefer I wait
> > > > > > for a while and work on it based on your new patch.
> > > > >
> > > > > I think most important part here is that we sync across all the different
> > > > > people pushing for better drm/alsa integration. What the solution looks
> > > > > like in the end doesn't matter much imo, as long as we don't end up with 3
> > > > > different things :-)
> > > >
> > > > Totally agree.
> > >
> > > Anyway just my thoughts, let's keep chatting.
> > >
> > > Cheers, Daniel
> > >
> > > > Thanks again!
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > >
> > > > > > Thanks a lot!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks again!
> > > > > > > >
> > > > > > > > > -Daniel
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Hans
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Modified by Cheng-Yi Chiang:
> > > > > > > > > > > - Add a section in MAINTAINER.
> > > > > > > > > > > - Changes connected and has_eld to bitfield of unsigned int.
> > > > > > > > > > > - Other minor fixes to pass checkpatch.pl --strict checks.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> > > > > > > > > > > ---
> > > > > > > > > > > The original patch is at
> > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverkuil@xs4all.nl
> > > > > > > > > > >
> > > > > > > > > > > MAINTAINERS | 6 ++
> > > > > > > > > > > drivers/video/Kconfig | 3 +
> > > > > > > > > > > drivers/video/Makefile | 1 +
> > > > > > > > > > > drivers/video/hdmi-notifier.c | 145 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > include/linux/hdmi-notifier.h | 112 ++++++++++++++++++++++++++
> > > > > > > > > > > 5 files changed, 267 insertions(+)
> > > > > > > > > > > create mode 100644 drivers/video/hdmi-notifier.c
> > > > > > > > > > > create mode 100644 include/linux/hdmi-notifier.h
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > > > > > > > index 5cfbea4ce575..ffb7376f9509 100644
> > > > > > > > > > > --- a/MAINTAINERS
> > > > > > > > > > > +++ b/MAINTAINERS
> > > > > > > > > > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> > > > > > > > > > > S: Maintained
> > > > > > > > > > > F: drivers/media/platform/vicodec/*
> > > > > > > > > > >
> > > > > > > > > > > +VIDEO FRAMEWORK
> > > > > > > > > > > +M: Hans Verkuil <hverkuil@xs4all.nl>
> > > > > > > > > > > +L: linux-media@vger.kernel.org
> > > > > > > > > > > +F: drivers/video/hdmi-notifier.*
> > > > > > > > > > > +S: Maintained
> > > > > > > > > > > +
> > > > > > > > > > > VIDEO MULTIPLEXER DRIVER
> > > > > > > > > > > M: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > L: linux-media@vger.kernel.org
> > > > > > > > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > > > > > > > > index 83d3d271ca15..000ba9bc0ae7 100644
> > > > > > > > > > > --- a/drivers/video/Kconfig
> > > > > > > > > > > +++ b/drivers/video/Kconfig
> > > > > > > > > > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> > > > > > > > > > > config HDMI
> > > > > > > > > > > bool
> > > > > > > > > > >
> > > > > > > > > > > +config HDMI_NOTIFIERS
> > > > > > > > > > > + bool
> > > > > > > > > > > +
> > > > > > > > > > > endif # HAS_IOMEM
> > > > > > > > > > >
> > > > > > > > > > > if VT
> > > > > > > > > > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > > > > > > > > > index df7650adede9..eff4736102ca 100644
> > > > > > > > > > > --- a/drivers/video/Makefile
> > > > > > > > > > > +++ b/drivers/video/Makefile
> > > > > > > > > > > @@ -1,6 +1,7 @@
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > obj-$(CONFIG_VGASTATE) += vgastate.o
> > > > > > > > > > > obj-$(CONFIG_HDMI) += hdmi.o
> > > > > > > > > > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_VT) += console/
> > > > > > > > > > > obj-$(CONFIG_FB_STI) += console/
> > > > > > > > > > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..d1eedf661648
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > @@ -0,0 +1,145 @@
> > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/export.h>
> > > > > > > > > > > +#include <linux/hdmi-notifier.h>
> > > > > > > > > > > +#include <linux/string.h>
> > > > > > > > > > > +#include <linux/slab.h>
> > > > > > > > > > > +#include <linux/list.h>
> > > > > > > > > > > +
> > > > > > > > > > > +static LIST_HEAD(hdmi_notifiers);
> > > > > > > > > > > +static DEFINE_MUTEX(hdmi_notifiers_lock);
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n;
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_for_each_entry(n, &hdmi_notifiers, head) {
> > > > > > > > > > > + if (n->dev == dev) {
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + return n;
> > > > > > > > > > > + }
> > > > > > > > > > > + }
> > > > > > > > > > > + n = kzalloc(sizeof(*n), GFP_KERNEL);
> > > > > > > > > > > + if (!n)
> > > > > > > > > > > + goto unlock;
> > > > > > > > > > > + n->dev = dev;
> > > > > > > > > > > + mutex_init(&n->lock);
> > > > > > > > > > > + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> > > > > > > > > > > + kref_init(&n->kref);
> > > > > > > > > > > + list_add_tail(&n->head, &hdmi_notifiers);
> > > > > > > > > > > +unlock:
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + return n;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> > > > > > > > > > > +
> > > > > > > > > > > +static void hdmi_notifier_release(struct kref *kref)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n =
> > > > > > > > > > > + container_of(kref, struct hdmi_notifier, kref);
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_del(&n->head);
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + kfree(n);
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + kref_put(&n->kref, hdmi_notifier_release);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->connected) {
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + if (n->edid_size)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_EDID, n);
> > > > > > > > > > > + if (n->has_eld)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_ELD, n);
> > > > > > > > > > > + }
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret == 0)
> > > > > > > > > > > + hdmi_notifier_put(n);
> > > > > > > > > > > + return ret;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = false;
> > > > > > > > > > > + n->has_eld = false;
> > > > > > > > > > > + n->edid_size = 0;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->edid_allocated_size < size) {
> > > > > > > > > > > + void *p = kmalloc(size, GFP_KERNEL);
> > > > > > > > > > > +
> > > > > > > > > > > + if (!p) {
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return -ENOMEM;
> > > > > > > > > > > + }
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + n->edid = p;
> > > > > > > > > > > + n->edid_allocated_size = size;
> > > > > > > > > > > + }
> > > > > > > > > > > + memcpy(n->edid, edid, size);
> > > > > > > > > > > + n->edid_size = size;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128])
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + memcpy(n->eld, eld, sizeof(n->eld));
> > > > > > > > > > > + n->has_eld = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> > > > > > > > > > > diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..c8f35110e3e3
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/include/linux/hdmi-notifier.h
> > > > > > > > > > > @@ -0,0 +1,112 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > + * hdmi-notifier.h - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +#define LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/types.h>
> > > > > > > > > > > +#include <linux/notifier.h>
> > > > > > > > > > > +#include <linux/kref.h>
> > > > > > > > > > > +
> > > > > > > > > > > +enum {
> > > > > > > > > > > + HDMI_CONNECTED,
> > > > > > > > > > > + HDMI_DISCONNECTED,
> > > > > > > > > > > + HDMI_NEW_EDID,
> > > > > > > > > > > + HDMI_NEW_ELD,
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +struct device;
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier {
> > > > > > > > > > > + /* Lock to protect callback registration and notification. */
> > > > > > > > > > > + struct mutex lock;
> > > > > > > > > > > + struct list_head head;
> > > > > > > > > > > + struct kref kref;
> > > > > > > > > > > + struct blocking_notifier_head notifiers;
> > > > > > > > > > > + struct device *dev;
> > > > > > > > > > > +
> > > > > > > > > > > + /* Current state */
> > > > > > > > > > > + unsigned int connected : 1;
> > > > > > > > > > > + unsigned int has_eld : 1;
> > > > > > > > > > > + unsigned char eld[128];
> > > > > > > > > > > + void *edid;
> > > > > > > > > > > + size_t edid_size;
> > > > > > > > > > > + size_t edid_allocated_size;
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_get - find or create a new hdmi_notifier for the given device.
> > > > > > > > > > > + * @dev: device that sends the events.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If a notifier for device @dev already exists, then increase the refcount
> > > > > > > > > > > + * and return that notifier.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If it doesn't exist, then allocate a new notifier struct and return a
> > > > > > > > > > > + * pointer to that new struct.
> > > > > > > > > > > + *
> > > > > > > > > > > + * Return NULL if the memory could not be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_put - decrease refcount and delete when the refcount reaches 0.
> > > > > > > > > > > + * @n: notifier
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_register - register the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_unregister - unregister the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n,
> > > > > > > > > > > + struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_connect - send a connect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_CONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_disconnect - send a disconnect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_DISCONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_edid - send a new EDID event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_EDID event to any registered parties.
> > > > > > > > > > > + * This function will make a copy the EDID so it can return -ENOMEM if
> > > > > > > > > > > + * no memory could be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_eld - send a new ELD event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_ELD event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128]);
> > > > > > > > > > > +
> > > > > > > > > > > +#endif
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Vetter
> > > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > > http://blog.ffwll.ch
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Vetter
> > > > > > > Software Engineer, Intel Corporation
> > > > > > > http://blog.ffwll.ch
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] drm/i915/execlists: Preempt-to-busy
From: Mika Kuoppala @ 2019-06-20 13:23 UTC (permalink / raw)
To: Chris Wilson, intel-gfx
In-Reply-To: <156103571913.664.2393652269100436806@skylake-alporthouse-com>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Quoting Mika Kuoppala (2019-06-20 13:41:26)
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>> > @@ -38,6 +39,10 @@ struct intel_context {
>> > struct i915_gem_context *gem_context;
>> > struct intel_engine_cs *engine;
>> > struct intel_engine_cs *inflight;
>> > +#define intel_context_inflight(ce) ptr_mask_bits((ce)->inflight, 2)
>> > +#define intel_context_inflight_count(ce) ptr_unmask_bits((ce)->inflight, 2)
>> > +#define intel_context_inflight_inc(ce) ptr_count_inc(&(ce)->inflight)
>> > +#define intel_context_inflight_dec(ce) ptr_count_dec(&(ce)->inflight)
>>
>> Just curious here that what you consider the advantages of carrying
>> this info with the pointer?
>
> Packing. I just need a bit to track status, and one for overflow.
>
>> > +static inline u32 intel_hws_preempt_address(struct intel_engine_cs *engine)
>> > +{
>> > + return (i915_ggtt_offset(engine->status_page.vma) +
>> > + I915_GEM_HWS_PREEMPT_ADDR);
>> > +}
>> > +
>> > +#define ring_pause(E) ((E)->status_page.addr[I915_GEM_HWS_PREEMPT])
>>
>> Scary. Please lets make a function of ring_pause and use
>> intel_write_status_page in it.
>
> I'd rather not unless you do __intel_write_state_page.
>
>> So I guess you have and you want squeeze the latency fruit.
>>
>> When we have everything in place, CI is green and
>> everyone is happy, then we tear it down?
>
> Been there, done that.
My fears come from csb. Granted, it is a diffent
thing with a different direction of writes.
>
>> > @@ -442,13 +443,11 @@ __unwind_incomplete_requests(struct intel_engine_cs *engine)
>> > struct intel_engine_cs *owner;
>> >
>> > if (i915_request_completed(rq))
>> > - break;
>> > + continue; /* XXX */
>>
>> Yeah, but what is the plan with the XXX.
>
> Mulling over tracking context not requests. We still end up with having
> to scan history within a context, so not yet seeing anything to
> encourage me to make the change. I worry about long request queues
> causing preemption latency, as this list is currently only trimmed in
> retirement.
>
> One idea in the background is for a scheduler (contemplating something
> like the isosynchronous MuQSS) and that might call for a change to
> using contexts as the primary, with requests within the contexts.
>
>> > @@ -1223,68 +1217,37 @@ static void process_csb(struct intel_engine_cs *engine)
>> > * status notifier.
>> > */
>> >
>> > - GEM_TRACE("%s csb[%d]: status=0x%08x:0x%08x, active=0x%x\n",
>> > + GEM_TRACE("%s csb[%d]: status=0x%08x:0x%08x\n",
>> > engine->name, head,
>> > - buf[2 * head + 0], buf[2 * head + 1],
>> > - execlists->active);
>> > + buf[2 * head + 0], buf[2 * head + 1]);
>> >
>> > status = buf[2 * head];
>> > - if (status & (GEN8_CTX_STATUS_IDLE_ACTIVE |
>> > - GEN8_CTX_STATUS_PREEMPTED))
>> > - execlists_set_active(execlists,
>> > - EXECLISTS_ACTIVE_HWACK);
>> > - if (status & GEN8_CTX_STATUS_ACTIVE_IDLE)
>> > - execlists_clear_active(execlists,
>> > - EXECLISTS_ACTIVE_HWACK);
>> > -
>> > - if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK))
>> > - continue;
>> > + if (status & GEN8_CTX_STATUS_IDLE_ACTIVE) {
>> > +promote:
>> > + GEM_BUG_ON(!assert_pending_valid(execlists, "promote"));
>> > + execlists->active =
>> > + memcpy(execlists->inflight,
>> > + execlists->pending,
>> > + execlists_num_ports(execlists) *
>> > + sizeof(*execlists->pending));
>> > + execlists->pending[0] = NULL;
>>
>> I can't decide if comment or a helper inline function would
>> serve better as documentation of between inflight and pending
>> movement.
>
> The magic is just this function, I think process_csb() reads quite
> nicely with the 3 branches and switching between different states. It's
> about 8 lines without the comments and asserts.
>
Agreed. It is more compact and more readable with this patch.
>> I guess it is better to be left as a future work after
>> the dust settles.
>>
>> Just general yearning for a similar kind of level of documentation
>> steps as in dequeue.
>>
>> >
>> > - /* We should never get a COMPLETED | IDLE_ACTIVE! */
>> > - GEM_BUG_ON(status & GEN8_CTX_STATUS_IDLE_ACTIVE);
>>
>> Is our assert coverage going to suffer?
>
> You've looked at the added asserts and tracing; I claim we get stronger.
>
>> > @@ -2514,15 +2452,29 @@ static u32 *gen8_emit_wa_tail(struct i915_request *request, u32 *cs)
>> > return cs;
>> > }
>> >
>> > +static u32 *emit_preempt_busywait(struct i915_request *request, u32 *cs)
>> > +{
>> > + *cs++ = MI_SEMAPHORE_WAIT |
>> > + MI_SEMAPHORE_GLOBAL_GTT |
>> > + MI_SEMAPHORE_POLL |
>> > + MI_SEMAPHORE_SAD_EQ_SDD;
>> > + *cs++ = 0;
>> > + *cs++ = intel_hws_preempt_address(request->engine);
>> > + *cs++ = 0;
>> > +
>> > + return cs;
>> > +}
>> > +
>> > static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
>> > {
>> > cs = gen8_emit_ggtt_write(cs,
>> > request->fence.seqno,
>> > request->timeline->hwsp_offset,
>> > 0);
>> > -
>> > *cs++ = MI_USER_INTERRUPT;
>> > +
>> > *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
>>
>> This was discussed in irc, could warrant a comment here of
>> why this is needed. Precious info.
>
> Why the ARB, for reasons of yore. The comment for why we need it is
> actually in bb_start.
>
> commit 279f5a00c9a9b39f4f6e9813e6d4da8c181d34c8
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date: Thu Oct 5 20:10:05 2017 +0100
>
> drm/i915/execlists: Add a comment for the extra MI_ARB_ENABLE
Ok, looks like it.
I do like the new way of handling ports.
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>
>
>> > + cs = emit_preempt_busywait(request, cs);
>
> Why we use the semaphore? That should be explained in dequeue upon
> setting up the preemption.
> -Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] hwmon: Convert remaining drivers to use SPDX identifier
From: Corentin Labbe @ 2019-06-20 13:23 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-hwmon, Jean Delvare, linux-kernel
In-Reply-To: <1561036786-23190-1-git-send-email-linux@roeck-us.net>
On Thu, Jun 20, 2019 at 06:19:46AM -0700, Guenter Roeck wrote:
> This gets rid of the unnecessary license boilerplate, and avoids
> having to deal with individual patches one by one.
>
> No functional changes intended.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/hwmon/adm1029.c | 10 ----------
> drivers/hwmon/adt7411.c | 5 +----
> drivers/hwmon/adt7475.c | 5 +----
> drivers/hwmon/iio_hwmon.c | 5 +----
> drivers/hwmon/max197.c | 5 +----
> drivers/hwmon/scpi-hwmon.c | 10 +---------
> 6 files changed, 5 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/hwmon/adm1029.c b/drivers/hwmon/adm1029.c
> index 388060ff85e7..f7752a5bef31 100644
> --- a/drivers/hwmon/adm1029.c
> +++ b/drivers/hwmon/adm1029.c
> @@ -10,16 +10,6 @@
> * Very rare chip please let me know if you use it
> *
> * http://www.analog.com/UploadedFiles/Data_Sheets/ADM1029.pdf
> - *
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License as published by
> - * the Free Software Foundation version 2 of the License
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> - * GNU General Public License for more details.
> */
>
> #include <linux/module.h>
For adm1029
Reviewed-by: Corentin Labbe <clabbe.montjoie@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/7] video: add HDMI state notifier support
From: Cheng-yi Chiang @ 2019-06-20 13:23 UTC (permalink / raw)
To: Cheng-yi Chiang, Hans Verkuil, linux-kernel,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Philipp Zabel,
Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Russell King, Andrzej Hajda, Laurent Pinchart, David Airlie,
Rob Herring, Heiko Stuebner, Doug Anderson, Dylan Reid, tzungbi,
linux-media,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
dri-devel, linux-arm-kernel, linux-rockchip, devicetree,
Dariusz Marcinkiewicz
Cc: Daniel Vetter
In-Reply-To: <20190620092506.GP12905@phenom.ffwll.local>
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > > > > > > > > > From: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > >
> > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > > > > > > > > > information from HDMI drivers to their CEC and audio counterparts.
> > > > > > > > > > >
> > > > > > > > > > > Based on an earlier version from Russell King:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/
> > > > > > > > > > >
> > > > > > > > > > > The hdmi_notifier is a reference counted object containing the HDMI state
> > > > > > > > > > > of an HDMI device.
> > > > > > > > > > >
> > > > > > > > > > > When a new notifier is registered the current state will be reported to
> > > > > > > > > > > that notifier at registration time.
> > > > > > > > > > >
> > > > > > > > > > > Based on Hans Verkuil's patch:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/
> > > > > > > > > >
> > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific notifier
> > > > > > > > > > found in drivers/media/cec/cec-notifier.c?
> > > > > > > > > >
> > > > > > > > > > I don't think it makes sense to have two notifier implementations in the kernel.
> > > > > > > > > > The original intention was to have the notifier deal with both CEC and ASoC
> > > > > > > > > > notifications, but there was not enough interest for the ASoC bits at the time
> > > > > > > > > > and it was dropped.
> > > > > > > > > >
> > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on that this
> > > > > > > > > > week. I'll CC you when I post those. Those might be a good starting point
> > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally intended.
> > > > > > > > > >
> > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
> > > > > > > > > > working on some nice cec-notifier improvements as well.
> > > > > > > > >
> > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi
> > > > > > > > > already in drm/drm_audio_component.h, but it's not used by anything
> > > > > > > > > outside of i915. Imo we should extend that, not reinvent a new wheel.
> > > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it is
> > > > > > > > specific to HDA.
> > > > > > > > I am not familiar with drm and HDA. I am not sure how applicable it
> > > > > > > > would be to report jack status to ASoC.
> > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
> > > > > > > > should be possible.
> > > > > > >
> > > > > > > Currently hda is the only user, but the idea was to make it more generic.
> > > > > > > Jack status in alsa is what drm calls connector status btw.
> > > > > > >
> > > > > > > So if we can take that as a baseline and extend it (probably needs some
> > > > > > > registration boilerplate and helpers to look up the right endpoint using
> > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), that
> > > > > > > would be great I think.
> > > > > > >
> > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for one
> > > > > > > > > case, as soon as you have multiple devices and need to make sure you get
> > > > > > > > > the update for the right one it all comes crashing down. Please create an
> > > > > > > > > api which registers for updates from a specific device only, plus
> > > > > > > > > something that has real callbacks (like the drm_audio_component.h thing we
> > > > > > > > > started already).
> > > > > > > >
> > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a
> > > > > > > > specific device only.
> > > > > > > > hdmi_notifier_get takes a device and return the notifier.
> > > > > > >
> > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier
> > > > > > > concerns addressed.
> > > > > > >
> > > > > > > > It seems that a major difference between drm_audio_components and
> > > > > > > > hdmi-notifier is that
> > > > > > > > drm_audio_components defines all supported ops in drm_audio_component_audio_ops.
> > > > > > > > On the other hand, hdmi-notifier passes different events using an enum
> > > > > > > > like HDMI_CONNECTED and let listener handle different events.
> > > > > > > > In this regard I agree with you that drm_audio_component is cleaner.
> > > > > > > > Anyway, I will look into it a bit more and see how it works.
> > > > > > >
> > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for
> > > > > > > registration, some _ops structure for the actual notifications, then
> > > > > > > there's a solid interface. I just really don't like the opaque void *
> > > > > > > interface notifier provides, it encourages abuse way too much.
> > > > > > >
> > > > > > > Ofc the registration side would then no longer be based on the notifier
> > > > > > > datastructure, list_head (like cec-notifier.c) of registeres devices with
> > > > > > > their _ops structure should be enough.
> > > > > > > -Daniel
> > > > > >
> > > > > > Hi Daniel,
> > > > > > Yes, I agree the above statement that we should have a more solid interface.
> > > > > >
> > > > > > Hi Hans,
> > > > > > I am not sure if I missed the patch.
> > > > > > Do you have a estimated timeline for new cec-notifier interface you
> > > > > > are working on?
> > > > > > It seems that your PoC patch needs Dariusz's patch to work.
> > > > > > I would like to seek your advice on whether I can proceed without your
> > > > > > patch and Dariusz's patch.
> > > > > >
> > > > > > I looked through the patch from Dariusz
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/21/389
> > > > > >
> > > > > > , and saw that you were thinking whether we should use cec-notifier
> > > > > > for both HDMI and CEC.
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/24/298
> > > > > >
> > > > > > Could you please let me know your latest thought on whether we should
> > > > > > reuse cec-notifier?
> > > > >
> > > > > Nah, see later in that thread, I think cec and audio seem to be different
> > > > > use-cases.
> > > > >
> > > > Ack
> > > > > But definitely a good idea to sync with Dariusz, I forgot to pull the two
> > > > > threads together. Thanks for doing that.
> > > > >
> > > > > > I agree with you that I should not proceed with hdmi-notifier. Reasons include:
> > > > > > 1. Method like cec_notifier_parse_hdmi_phandle can be reused. It is
> > > > > > error prone to memory leak if it is implemented by user, like the
> > > > > > patch in hdmi-codec.c in this series did not handle the ref count.
> > > > > > 2. cec-notifier has a simpler implementation of register / unregister
> > > > > > because there is no call chain. I am not aware of the need for
> > > > > > hdmi-notifier to support a chain of callbacks. So I think that call
> > > > > > chain support can be removed.
> > > > > >
> > > > > > If I go ahead and add a new interface to register ops to handle
> > > > > > connector status report from cec-notifer, based on current
> > > > > > cec-notifier, do you think that would work ?
> > > > > > I think it might work if I add another cec_notifier object inside
> > > > > > dw-hdmi.c, but only for HDMI jack reporting, not for CEC related
> > > > > > reporting.
> > > > > >
> > > > > > And after some investigation, I realize that my requirement is even
> > > > > > simpler. I don't need hdmi_event_new_edid and hdmi_event_new_eld in my
> > > > > > use case.
> > > > >
> > > > > Yeah, connector status is how we started with the drm/alsa interface in
> > > > > i915 too, but later on had to extend it. I think eventually we'll need it
> > > > > all, that's why I suggested to use that as the interface between drm and
> > > > > alsa side, but augmented with some register/unregister and bind logic.
> > > > >
> > > > Hi Daniel,
> > > > Sorry for the late reply.
> > > > I spent some time investigating how drm_audio_component works.
> > > > The coupling of HDA in drm_audio_component framework makes the
> > > > register/unregister logic looks complicated to me as I don't use HDA
> > > > in my use case.
> > > > After some time, I found another patch series which also use component
> > > > framework to communicate between drm and mei world.
> > > >
> > > > https://patchwork.kernel.org/patch/10824527/
> > > >
> > > > And from that patch, I realized that I can follow the similar approach
> > > > to register a master component on ALSA side, a slave component on DRM
> > > > side, and use device and subcomponent to match them.
> > >
> > > Sorry for the confusion here. My suggestion is _not_ to use the component
> > > framework. That's only meant for one-off special case solutions. For that
> > > part I think you need to build a new register/unregister/bind/unbind
> > > infrastructure, like we have for lots of other things in the kernel
> > > already (clocks, gpio, drm_panel, drm_bridge as just a few examples).
> > >
> >
> > Hi Daniel,
> > Thank you for the prompt reply and guidance.
> >
> > I see. I was not aware that we should avoid using component framework.
> > Your example of drm_panel seems great.
> > I plan is to reuse drm_audio_components like this:
> > A LIST_HEAD holding the list of drm_audio_components instances, and add API
> > drm_audio_comp_init,
> > _add, _remove, _attach, _detach.
> > And for DRM side to look up the instance to use, we can use similar
> > approach like of_drm_find_panel, that is, using device tree node.
>
> Sounds good. I guess somewhere in there you'll use of_node/DT information
> to make sure you have the right audio component? Just to make sure we're
> agreeing on the design completely.
ACK.
I need to check closer. I will use of_node/DT information,
but it might be the other way around as machine driver can get the
hdmi node and hence hdmi device,
and that device can be passed to codec driver to register a component
with the device.
So the register mechanism is more like original hdmi_notifier.
>
>
> > > My suggestion with the i915/hda interface is to build on the actual
> > > interface for signalling connector status and exchanging eld and stuff
> > > like that.
> > >
> >
> > I agree with using this interface. But in my use case there is no much
> > data to be exchanged.
> > Only the connector status needs to be passed from DRM to ALSA world.
> > If in the future there is need for ALSA to make some call, that ops
> > can be added to drm_audio_component_ops.
>
> Yeah I think it's ok to not implement everyhing. Iirc we started with only
> the connector status too, then extended that to sharing the eld.
>
> There's also some i915/had hacks (clocks without using clock framework,
> power domains without using power framework), where for DT platforms we
> probably want to do this right.
>
> Looking at the entire thing we might need to create new _ops structures,
> or at least refactor them quite a bit. But we can improve things
> iteratively imo.
ACK
>
>
> > > > I should be able to do this without touching anything specific to HDA.
> > > > After that, DRM world should be able to use the ops in
> > > > drm_audio_component_audio_ops to notify ALSA world some event when
> > > > there is something happen in DRM world.
> > > > Currently the ops like pin_eld_notify, pin2port are too specific to HDA.
> > > > I think I can add an ops to drm_audio_component_audio_ops to convey
> > > > connector status.
> > >
> > > Hm why? The pin2port is maybe not the best one, since port is an intel
> > > construct, and pin a hda construct. So we'd need to change those to talk
> > > in terms of the higher-level concepts (alsa output pin and drm crtc
> > > probably).
> > >
> >
> > I took more look into how information of audio being present or not is
> > passed between DRM and ALSA world,
> > taking drivers/gpu/drm/i915/intel_audio.c and
> > sound/soc/codecs/hdac_hdmi.c as example.
> > I see the sequence is DRM side to call pin_eld_notify ops with port
> > and pipe to ALSA side.
> > Then, ALSA side calls get_eld ops with port and pipe to look up
> > whether the saved encoder has audio_connector.
> >
> > However, my use case on RK3288 is different in that ALSA side does not
> > need to get ELD.
> > I think adding an ops like connector_status() for DRM side to call in
> > parallel to pin_eld_notify is reasonable.
> > Both DRM side and ALSA side can choose what is the desired ops to be
> > implemented as these ops can be optional.
>
> I think pin_eld_notify and get_eld are just mislabeled, they give you both
> eld and status (the bool *enabled in get_eld). Maybe we should rename them
> to get_status and pin_status_notify?
ACK
>
> > > The other stuff should work a bit better. Either way my idea was to evolve
> > > that interface (and put in the place the required type-casting for
> > > i915/hda), since more users increases the odds that it actually is a good
> > > design.
> > >
> > Sorry I don't understand this part.
> > Could you please elaborate more about type-casting for i915/hda ?
> >
> > TBH, If possible, I would like to minimize the change I'll need to
> > make to i915/hda because of my limited knowledge of i915/hda and my
> > limited bandwidth.
> >
> > I would like to point out the scope of this problem to help the discussion.
> > I think this is a common need on boards using ALSA hdmi-codec driver.
> > Currently, there are many DRM drivers resorted to hdmi_codec_ops
> > approach to let ALSA world talks to DRM world.
> > That hdmi_codec_ops approach came around 2016 so it was before
> > drm_audio_component was introduced.
> > As for how jack status is reported for these boards, I am not sure,
> > maybe with local patches of hdmi-notifier.
> > So this is not a one-off change for RK3288 only. I believe other
> > boards will benefit from this jack reporting feature as well.
> >
> > As for extending and improving the interface of drm_audio_component so
> > more users can adopt it,
> > I think the ops in hdmi_codec_ops are good candidates to be moved to
> > drm_audio_component to consolidate the interface between DRM and ALSA
> > better.
> > That said, I don't feel a strong need to change i915/hda if the
> > purpose is to let more users use drm_audio_component.
> >
> > I can drew these changes in three stages:
> > 1. Add the infrastructure to add/remove/attach/detach
> > drm_audio_component (like how drm_panel does), and add
> > connector_status ops.
> > 2. Move ops in hdmi_codec_ops into drm_audio_components.
> > 3. Desired change of i915/hda (I am not clear about this part)
> >
> > I can help with 1 and 2 as Chromium tree have at least RK3288 and
> > MT8173 SoC using hdmi-codec driver so it is easier for me to try
> > patches.
> > And there may be more in the future.
> >
> > Thanks again for the patience.
> > I am not familiar with DRM so it takes me more time to digest your
> > comment and reply.
>
> Hm sorry, I totally forgot about this again, iirc I looked at this.
>
> Yeah fully agreeing that hdmi_audio_code is probably a better starting
> point. Problem is that becuase hdmi_codec is built on top of platform
> device it's quite a bit harder to extend with callbacks and things like
> that, without breaking the driver model.
>
> I need to think about this more, but if all we need to look at is
> hdmi_codec, then I think this becomes a lot easier. And we can ignore
> drm_audio_component.h completely.
It is surprising that you think this way.
Maybe the original patch before hdmi-notifier was introduced is the
better way to solve this issue, if we only need to look at hdmi_codec.
The history of hdmi_codec driver is in this patch series:
https://lore.kernel.org/patchwork/patch/539656/
There was a callback mechanism implemented between dw-hdmi and hdmi
codec driver.
It was later consolidated by Doug in this patch for better jack status
reporting:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/
I am not sure why the original patch series did not get fully accepted
in the upstream.
It was quite long time ago.
But if you think this might be the right way to do, then it is even
better for us because the patch series and Doug's patch had been quite
stable
on our RK3288 products for about four years with plenty of users, so
we have much higher confidence in them.
I can rebase and clean up them and post another patch for review.
Please let me know what approach you feel is better.
Thanks again!
>
> -Daniel
>
>
> >
> > > > I will work toward this approach these days.
> > > > If you have other thought please let me know.
> > > > Thanks!
> > > >
> > > > > > I just need to report the connector status from synopsys/dw-hdmi.c to
> > > > > > codecs/hdmi-codec.c for codec driver to update the jack status.
> > > > > > Do you think I can proceed in this direction ? Or do you prefer I wait
> > > > > > for a while and work on it based on your new patch.
> > > > >
> > > > > I think most important part here is that we sync across all the different
> > > > > people pushing for better drm/alsa integration. What the solution looks
> > > > > like in the end doesn't matter much imo, as long as we don't end up with 3
> > > > > different things :-)
> > > >
> > > > Totally agree.
> > >
> > > Anyway just my thoughts, let's keep chatting.
> > >
> > > Cheers, Daniel
> > >
> > > > Thanks again!
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > >
> > > > > > Thanks a lot!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks again!
> > > > > > > >
> > > > > > > > > -Daniel
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Hans
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Modified by Cheng-Yi Chiang:
> > > > > > > > > > > - Add a section in MAINTAINER.
> > > > > > > > > > > - Changes connected and has_eld to bitfield of unsigned int.
> > > > > > > > > > > - Other minor fixes to pass checkpatch.pl --strict checks.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> > > > > > > > > > > ---
> > > > > > > > > > > The original patch is at
> > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverkuil@xs4all.nl
> > > > > > > > > > >
> > > > > > > > > > > MAINTAINERS | 6 ++
> > > > > > > > > > > drivers/video/Kconfig | 3 +
> > > > > > > > > > > drivers/video/Makefile | 1 +
> > > > > > > > > > > drivers/video/hdmi-notifier.c | 145 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > include/linux/hdmi-notifier.h | 112 ++++++++++++++++++++++++++
> > > > > > > > > > > 5 files changed, 267 insertions(+)
> > > > > > > > > > > create mode 100644 drivers/video/hdmi-notifier.c
> > > > > > > > > > > create mode 100644 include/linux/hdmi-notifier.h
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > > > > > > > index 5cfbea4ce575..ffb7376f9509 100644
> > > > > > > > > > > --- a/MAINTAINERS
> > > > > > > > > > > +++ b/MAINTAINERS
> > > > > > > > > > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> > > > > > > > > > > S: Maintained
> > > > > > > > > > > F: drivers/media/platform/vicodec/*
> > > > > > > > > > >
> > > > > > > > > > > +VIDEO FRAMEWORK
> > > > > > > > > > > +M: Hans Verkuil <hverkuil@xs4all.nl>
> > > > > > > > > > > +L: linux-media@vger.kernel.org
> > > > > > > > > > > +F: drivers/video/hdmi-notifier.*
> > > > > > > > > > > +S: Maintained
> > > > > > > > > > > +
> > > > > > > > > > > VIDEO MULTIPLEXER DRIVER
> > > > > > > > > > > M: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > L: linux-media@vger.kernel.org
> > > > > > > > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > > > > > > > > index 83d3d271ca15..000ba9bc0ae7 100644
> > > > > > > > > > > --- a/drivers/video/Kconfig
> > > > > > > > > > > +++ b/drivers/video/Kconfig
> > > > > > > > > > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> > > > > > > > > > > config HDMI
> > > > > > > > > > > bool
> > > > > > > > > > >
> > > > > > > > > > > +config HDMI_NOTIFIERS
> > > > > > > > > > > + bool
> > > > > > > > > > > +
> > > > > > > > > > > endif # HAS_IOMEM
> > > > > > > > > > >
> > > > > > > > > > > if VT
> > > > > > > > > > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > > > > > > > > > index df7650adede9..eff4736102ca 100644
> > > > > > > > > > > --- a/drivers/video/Makefile
> > > > > > > > > > > +++ b/drivers/video/Makefile
> > > > > > > > > > > @@ -1,6 +1,7 @@
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > obj-$(CONFIG_VGASTATE) += vgastate.o
> > > > > > > > > > > obj-$(CONFIG_HDMI) += hdmi.o
> > > > > > > > > > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_VT) += console/
> > > > > > > > > > > obj-$(CONFIG_FB_STI) += console/
> > > > > > > > > > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..d1eedf661648
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > @@ -0,0 +1,145 @@
> > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/export.h>
> > > > > > > > > > > +#include <linux/hdmi-notifier.h>
> > > > > > > > > > > +#include <linux/string.h>
> > > > > > > > > > > +#include <linux/slab.h>
> > > > > > > > > > > +#include <linux/list.h>
> > > > > > > > > > > +
> > > > > > > > > > > +static LIST_HEAD(hdmi_notifiers);
> > > > > > > > > > > +static DEFINE_MUTEX(hdmi_notifiers_lock);
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n;
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_for_each_entry(n, &hdmi_notifiers, head) {
> > > > > > > > > > > + if (n->dev == dev) {
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + return n;
> > > > > > > > > > > + }
> > > > > > > > > > > + }
> > > > > > > > > > > + n = kzalloc(sizeof(*n), GFP_KERNEL);
> > > > > > > > > > > + if (!n)
> > > > > > > > > > > + goto unlock;
> > > > > > > > > > > + n->dev = dev;
> > > > > > > > > > > + mutex_init(&n->lock);
> > > > > > > > > > > + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> > > > > > > > > > > + kref_init(&n->kref);
> > > > > > > > > > > + list_add_tail(&n->head, &hdmi_notifiers);
> > > > > > > > > > > +unlock:
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + return n;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> > > > > > > > > > > +
> > > > > > > > > > > +static void hdmi_notifier_release(struct kref *kref)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n =
> > > > > > > > > > > + container_of(kref, struct hdmi_notifier, kref);
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_del(&n->head);
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + kfree(n);
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + kref_put(&n->kref, hdmi_notifier_release);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->connected) {
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + if (n->edid_size)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_EDID, n);
> > > > > > > > > > > + if (n->has_eld)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_ELD, n);
> > > > > > > > > > > + }
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret == 0)
> > > > > > > > > > > + hdmi_notifier_put(n);
> > > > > > > > > > > + return ret;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = false;
> > > > > > > > > > > + n->has_eld = false;
> > > > > > > > > > > + n->edid_size = 0;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->edid_allocated_size < size) {
> > > > > > > > > > > + void *p = kmalloc(size, GFP_KERNEL);
> > > > > > > > > > > +
> > > > > > > > > > > + if (!p) {
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return -ENOMEM;
> > > > > > > > > > > + }
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + n->edid = p;
> > > > > > > > > > > + n->edid_allocated_size = size;
> > > > > > > > > > > + }
> > > > > > > > > > > + memcpy(n->edid, edid, size);
> > > > > > > > > > > + n->edid_size = size;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128])
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + memcpy(n->eld, eld, sizeof(n->eld));
> > > > > > > > > > > + n->has_eld = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> > > > > > > > > > > diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..c8f35110e3e3
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/include/linux/hdmi-notifier.h
> > > > > > > > > > > @@ -0,0 +1,112 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > + * hdmi-notifier.h - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +#define LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/types.h>
> > > > > > > > > > > +#include <linux/notifier.h>
> > > > > > > > > > > +#include <linux/kref.h>
> > > > > > > > > > > +
> > > > > > > > > > > +enum {
> > > > > > > > > > > + HDMI_CONNECTED,
> > > > > > > > > > > + HDMI_DISCONNECTED,
> > > > > > > > > > > + HDMI_NEW_EDID,
> > > > > > > > > > > + HDMI_NEW_ELD,
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +struct device;
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier {
> > > > > > > > > > > + /* Lock to protect callback registration and notification. */
> > > > > > > > > > > + struct mutex lock;
> > > > > > > > > > > + struct list_head head;
> > > > > > > > > > > + struct kref kref;
> > > > > > > > > > > + struct blocking_notifier_head notifiers;
> > > > > > > > > > > + struct device *dev;
> > > > > > > > > > > +
> > > > > > > > > > > + /* Current state */
> > > > > > > > > > > + unsigned int connected : 1;
> > > > > > > > > > > + unsigned int has_eld : 1;
> > > > > > > > > > > + unsigned char eld[128];
> > > > > > > > > > > + void *edid;
> > > > > > > > > > > + size_t edid_size;
> > > > > > > > > > > + size_t edid_allocated_size;
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_get - find or create a new hdmi_notifier for the given device.
> > > > > > > > > > > + * @dev: device that sends the events.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If a notifier for device @dev already exists, then increase the refcount
> > > > > > > > > > > + * and return that notifier.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If it doesn't exist, then allocate a new notifier struct and return a
> > > > > > > > > > > + * pointer to that new struct.
> > > > > > > > > > > + *
> > > > > > > > > > > + * Return NULL if the memory could not be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_put - decrease refcount and delete when the refcount reaches 0.
> > > > > > > > > > > + * @n: notifier
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_register - register the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_unregister - unregister the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n,
> > > > > > > > > > > + struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_connect - send a connect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_CONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_disconnect - send a disconnect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_DISCONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_edid - send a new EDID event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_EDID event to any registered parties.
> > > > > > > > > > > + * This function will make a copy the EDID so it can return -ENOMEM if
> > > > > > > > > > > + * no memory could be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_eld - send a new ELD event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_ELD event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128]);
> > > > > > > > > > > +
> > > > > > > > > > > +#endif
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Vetter
> > > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > > http://blog.ffwll.ch
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Vetter
> > > > > > > Software Engineer, Intel Corporation
> > > > > > > http://blog.ffwll.ch
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 1/7] video: add HDMI state notifier support
From: Cheng-yi Chiang @ 2019-06-20 13:23 UTC (permalink / raw)
To: Cheng-yi Chiang, Hans Verkuil, linux-kernel,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Philipp Zabel,
Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Russell King, Andrzej Hajda, Laurent Pinchart, David Airlie,
Rob Herring, Heiko Stuebner, Doug Anderson, Dylan Reid, tzungbi,
linux-media,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
dri-devel
In-Reply-To: <20190620092506.GP12905@phenom.ffwll.local>
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > > > > > > > > > From: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > >
> > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > > > > > > > > > information from HDMI drivers to their CEC and audio counterparts.
> > > > > > > > > > >
> > > > > > > > > > > Based on an earlier version from Russell King:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/
> > > > > > > > > > >
> > > > > > > > > > > The hdmi_notifier is a reference counted object containing the HDMI state
> > > > > > > > > > > of an HDMI device.
> > > > > > > > > > >
> > > > > > > > > > > When a new notifier is registered the current state will be reported to
> > > > > > > > > > > that notifier at registration time.
> > > > > > > > > > >
> > > > > > > > > > > Based on Hans Verkuil's patch:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/
> > > > > > > > > >
> > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific notifier
> > > > > > > > > > found in drivers/media/cec/cec-notifier.c?
> > > > > > > > > >
> > > > > > > > > > I don't think it makes sense to have two notifier implementations in the kernel.
> > > > > > > > > > The original intention was to have the notifier deal with both CEC and ASoC
> > > > > > > > > > notifications, but there was not enough interest for the ASoC bits at the time
> > > > > > > > > > and it was dropped.
> > > > > > > > > >
> > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on that this
> > > > > > > > > > week. I'll CC you when I post those. Those might be a good starting point
> > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally intended.
> > > > > > > > > >
> > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
> > > > > > > > > > working on some nice cec-notifier improvements as well.
> > > > > > > > >
> > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi
> > > > > > > > > already in drm/drm_audio_component.h, but it's not used by anything
> > > > > > > > > outside of i915. Imo we should extend that, not reinvent a new wheel.
> > > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it is
> > > > > > > > specific to HDA.
> > > > > > > > I am not familiar with drm and HDA. I am not sure how applicable it
> > > > > > > > would be to report jack status to ASoC.
> > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
> > > > > > > > should be possible.
> > > > > > >
> > > > > > > Currently hda is the only user, but the idea was to make it more generic.
> > > > > > > Jack status in alsa is what drm calls connector status btw.
> > > > > > >
> > > > > > > So if we can take that as a baseline and extend it (probably needs some
> > > > > > > registration boilerplate and helpers to look up the right endpoint using
> > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), that
> > > > > > > would be great I think.
> > > > > > >
> > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for one
> > > > > > > > > case, as soon as you have multiple devices and need to make sure you get
> > > > > > > > > the update for the right one it all comes crashing down. Please create an
> > > > > > > > > api which registers for updates from a specific device only, plus
> > > > > > > > > something that has real callbacks (like the drm_audio_component.h thing we
> > > > > > > > > started already).
> > > > > > > >
> > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a
> > > > > > > > specific device only.
> > > > > > > > hdmi_notifier_get takes a device and return the notifier.
> > > > > > >
> > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier
> > > > > > > concerns addressed.
> > > > > > >
> > > > > > > > It seems that a major difference between drm_audio_components and
> > > > > > > > hdmi-notifier is that
> > > > > > > > drm_audio_components defines all supported ops in drm_audio_component_audio_ops.
> > > > > > > > On the other hand, hdmi-notifier passes different events using an enum
> > > > > > > > like HDMI_CONNECTED and let listener handle different events.
> > > > > > > > In this regard I agree with you that drm_audio_component is cleaner.
> > > > > > > > Anyway, I will look into it a bit more and see how it works.
> > > > > > >
> > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for
> > > > > > > registration, some _ops structure for the actual notifications, then
> > > > > > > there's a solid interface. I just really don't like the opaque void *
> > > > > > > interface notifier provides, it encourages abuse way too much.
> > > > > > >
> > > > > > > Ofc the registration side would then no longer be based on the notifier
> > > > > > > datastructure, list_head (like cec-notifier.c) of registeres devices with
> > > > > > > their _ops structure should be enough.
> > > > > > > -Daniel
> > > > > >
> > > > > > Hi Daniel,
> > > > > > Yes, I agree the above statement that we should have a more solid interface.
> > > > > >
> > > > > > Hi Hans,
> > > > > > I am not sure if I missed the patch.
> > > > > > Do you have a estimated timeline for new cec-notifier interface you
> > > > > > are working on?
> > > > > > It seems that your PoC patch needs Dariusz's patch to work.
> > > > > > I would like to seek your advice on whether I can proceed without your
> > > > > > patch and Dariusz's patch.
> > > > > >
> > > > > > I looked through the patch from Dariusz
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/21/389
> > > > > >
> > > > > > , and saw that you were thinking whether we should use cec-notifier
> > > > > > for both HDMI and CEC.
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/24/298
> > > > > >
> > > > > > Could you please let me know your latest thought on whether we should
> > > > > > reuse cec-notifier?
> > > > >
> > > > > Nah, see later in that thread, I think cec and audio seem to be different
> > > > > use-cases.
> > > > >
> > > > Ack
> > > > > But definitely a good idea to sync with Dariusz, I forgot to pull the two
> > > > > threads together. Thanks for doing that.
> > > > >
> > > > > > I agree with you that I should not proceed with hdmi-notifier. Reasons include:
> > > > > > 1. Method like cec_notifier_parse_hdmi_phandle can be reused. It is
> > > > > > error prone to memory leak if it is implemented by user, like the
> > > > > > patch in hdmi-codec.c in this series did not handle the ref count.
> > > > > > 2. cec-notifier has a simpler implementation of register / unregister
> > > > > > because there is no call chain. I am not aware of the need for
> > > > > > hdmi-notifier to support a chain of callbacks. So I think that call
> > > > > > chain support can be removed.
> > > > > >
> > > > > > If I go ahead and add a new interface to register ops to handle
> > > > > > connector status report from cec-notifer, based on current
> > > > > > cec-notifier, do you think that would work ?
> > > > > > I think it might work if I add another cec_notifier object inside
> > > > > > dw-hdmi.c, but only for HDMI jack reporting, not for CEC related
> > > > > > reporting.
> > > > > >
> > > > > > And after some investigation, I realize that my requirement is even
> > > > > > simpler. I don't need hdmi_event_new_edid and hdmi_event_new_eld in my
> > > > > > use case.
> > > > >
> > > > > Yeah, connector status is how we started with the drm/alsa interface in
> > > > > i915 too, but later on had to extend it. I think eventually we'll need it
> > > > > all, that's why I suggested to use that as the interface between drm and
> > > > > alsa side, but augmented with some register/unregister and bind logic.
> > > > >
> > > > Hi Daniel,
> > > > Sorry for the late reply.
> > > > I spent some time investigating how drm_audio_component works.
> > > > The coupling of HDA in drm_audio_component framework makes the
> > > > register/unregister logic looks complicated to me as I don't use HDA
> > > > in my use case.
> > > > After some time, I found another patch series which also use component
> > > > framework to communicate between drm and mei world.
> > > >
> > > > https://patchwork.kernel.org/patch/10824527/
> > > >
> > > > And from that patch, I realized that I can follow the similar approach
> > > > to register a master component on ALSA side, a slave component on DRM
> > > > side, and use device and subcomponent to match them.
> > >
> > > Sorry for the confusion here. My suggestion is _not_ to use the component
> > > framework. That's only meant for one-off special case solutions. For that
> > > part I think you need to build a new register/unregister/bind/unbind
> > > infrastructure, like we have for lots of other things in the kernel
> > > already (clocks, gpio, drm_panel, drm_bridge as just a few examples).
> > >
> >
> > Hi Daniel,
> > Thank you for the prompt reply and guidance.
> >
> > I see. I was not aware that we should avoid using component framework.
> > Your example of drm_panel seems great.
> > I plan is to reuse drm_audio_components like this:
> > A LIST_HEAD holding the list of drm_audio_components instances, and add API
> > drm_audio_comp_init,
> > _add, _remove, _attach, _detach.
> > And for DRM side to look up the instance to use, we can use similar
> > approach like of_drm_find_panel, that is, using device tree node.
>
> Sounds good. I guess somewhere in there you'll use of_node/DT information
> to make sure you have the right audio component? Just to make sure we're
> agreeing on the design completely.
ACK.
I need to check closer. I will use of_node/DT information,
but it might be the other way around as machine driver can get the
hdmi node and hence hdmi device,
and that device can be passed to codec driver to register a component
with the device.
So the register mechanism is more like original hdmi_notifier.
>
>
> > > My suggestion with the i915/hda interface is to build on the actual
> > > interface for signalling connector status and exchanging eld and stuff
> > > like that.
> > >
> >
> > I agree with using this interface. But in my use case there is no much
> > data to be exchanged.
> > Only the connector status needs to be passed from DRM to ALSA world.
> > If in the future there is need for ALSA to make some call, that ops
> > can be added to drm_audio_component_ops.
>
> Yeah I think it's ok to not implement everyhing. Iirc we started with only
> the connector status too, then extended that to sharing the eld.
>
> There's also some i915/had hacks (clocks without using clock framework,
> power domains without using power framework), where for DT platforms we
> probably want to do this right.
>
> Looking at the entire thing we might need to create new _ops structures,
> or at least refactor them quite a bit. But we can improve things
> iteratively imo.
ACK
>
>
> > > > I should be able to do this without touching anything specific to HDA.
> > > > After that, DRM world should be able to use the ops in
> > > > drm_audio_component_audio_ops to notify ALSA world some event when
> > > > there is something happen in DRM world.
> > > > Currently the ops like pin_eld_notify, pin2port are too specific to HDA.
> > > > I think I can add an ops to drm_audio_component_audio_ops to convey
> > > > connector status.
> > >
> > > Hm why? The pin2port is maybe not the best one, since port is an intel
> > > construct, and pin a hda construct. So we'd need to change those to talk
> > > in terms of the higher-level concepts (alsa output pin and drm crtc
> > > probably).
> > >
> >
> > I took more look into how information of audio being present or not is
> > passed between DRM and ALSA world,
> > taking drivers/gpu/drm/i915/intel_audio.c and
> > sound/soc/codecs/hdac_hdmi.c as example.
> > I see the sequence is DRM side to call pin_eld_notify ops with port
> > and pipe to ALSA side.
> > Then, ALSA side calls get_eld ops with port and pipe to look up
> > whether the saved encoder has audio_connector.
> >
> > However, my use case on RK3288 is different in that ALSA side does not
> > need to get ELD.
> > I think adding an ops like connector_status() for DRM side to call in
> > parallel to pin_eld_notify is reasonable.
> > Both DRM side and ALSA side can choose what is the desired ops to be
> > implemented as these ops can be optional.
>
> I think pin_eld_notify and get_eld are just mislabeled, they give you both
> eld and status (the bool *enabled in get_eld). Maybe we should rename them
> to get_status and pin_status_notify?
ACK
>
> > > The other stuff should work a bit better. Either way my idea was to evolve
> > > that interface (and put in the place the required type-casting for
> > > i915/hda), since more users increases the odds that it actually is a good
> > > design.
> > >
> > Sorry I don't understand this part.
> > Could you please elaborate more about type-casting for i915/hda ?
> >
> > TBH, If possible, I would like to minimize the change I'll need to
> > make to i915/hda because of my limited knowledge of i915/hda and my
> > limited bandwidth.
> >
> > I would like to point out the scope of this problem to help the discussion.
> > I think this is a common need on boards using ALSA hdmi-codec driver.
> > Currently, there are many DRM drivers resorted to hdmi_codec_ops
> > approach to let ALSA world talks to DRM world.
> > That hdmi_codec_ops approach came around 2016 so it was before
> > drm_audio_component was introduced.
> > As for how jack status is reported for these boards, I am not sure,
> > maybe with local patches of hdmi-notifier.
> > So this is not a one-off change for RK3288 only. I believe other
> > boards will benefit from this jack reporting feature as well.
> >
> > As for extending and improving the interface of drm_audio_component so
> > more users can adopt it,
> > I think the ops in hdmi_codec_ops are good candidates to be moved to
> > drm_audio_component to consolidate the interface between DRM and ALSA
> > better.
> > That said, I don't feel a strong need to change i915/hda if the
> > purpose is to let more users use drm_audio_component.
> >
> > I can drew these changes in three stages:
> > 1. Add the infrastructure to add/remove/attach/detach
> > drm_audio_component (like how drm_panel does), and add
> > connector_status ops.
> > 2. Move ops in hdmi_codec_ops into drm_audio_components.
> > 3. Desired change of i915/hda (I am not clear about this part)
> >
> > I can help with 1 and 2 as Chromium tree have at least RK3288 and
> > MT8173 SoC using hdmi-codec driver so it is easier for me to try
> > patches.
> > And there may be more in the future.
> >
> > Thanks again for the patience.
> > I am not familiar with DRM so it takes me more time to digest your
> > comment and reply.
>
> Hm sorry, I totally forgot about this again, iirc I looked at this.
>
> Yeah fully agreeing that hdmi_audio_code is probably a better starting
> point. Problem is that becuase hdmi_codec is built on top of platform
> device it's quite a bit harder to extend with callbacks and things like
> that, without breaking the driver model.
>
> I need to think about this more, but if all we need to look at is
> hdmi_codec, then I think this becomes a lot easier. And we can ignore
> drm_audio_component.h completely.
It is surprising that you think this way.
Maybe the original patch before hdmi-notifier was introduced is the
better way to solve this issue, if we only need to look at hdmi_codec.
The history of hdmi_codec driver is in this patch series:
https://lore.kernel.org/patchwork/patch/539656/
There was a callback mechanism implemented between dw-hdmi and hdmi
codec driver.
It was later consolidated by Doug in this patch for better jack status
reporting:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/
I am not sure why the original patch series did not get fully accepted
in the upstream.
It was quite long time ago.
But if you think this might be the right way to do, then it is even
better for us because the patch series and Doug's patch had been quite
stable
on our RK3288 products for about four years with plenty of users, so
we have much higher confidence in them.
I can rebase and clean up them and post another patch for review.
Please let me know what approach you feel is better.
Thanks again!
>
> -Daniel
>
>
> >
> > > > I will work toward this approach these days.
> > > > If you have other thought please let me know.
> > > > Thanks!
> > > >
> > > > > > I just need to report the connector status from synopsys/dw-hdmi.c to
> > > > > > codecs/hdmi-codec.c for codec driver to update the jack status.
> > > > > > Do you think I can proceed in this direction ? Or do you prefer I wait
> > > > > > for a while and work on it based on your new patch.
> > > > >
> > > > > I think most important part here is that we sync across all the different
> > > > > people pushing for better drm/alsa integration. What the solution looks
> > > > > like in the end doesn't matter much imo, as long as we don't end up with 3
> > > > > different things :-)
> > > >
> > > > Totally agree.
> > >
> > > Anyway just my thoughts, let's keep chatting.
> > >
> > > Cheers, Daniel
> > >
> > > > Thanks again!
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > >
> > > > > > Thanks a lot!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks again!
> > > > > > > >
> > > > > > > > > -Daniel
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Hans
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Modified by Cheng-Yi Chiang:
> > > > > > > > > > > - Add a section in MAINTAINER.
> > > > > > > > > > > - Changes connected and has_eld to bitfield of unsigned int.
> > > > > > > > > > > - Other minor fixes to pass checkpatch.pl --strict checks.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> > > > > > > > > > > ---
> > > > > > > > > > > The original patch is at
> > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverkuil@xs4all.nl
> > > > > > > > > > >
> > > > > > > > > > > MAINTAINERS | 6 ++
> > > > > > > > > > > drivers/video/Kconfig | 3 +
> > > > > > > > > > > drivers/video/Makefile | 1 +
> > > > > > > > > > > drivers/video/hdmi-notifier.c | 145 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > include/linux/hdmi-notifier.h | 112 ++++++++++++++++++++++++++
> > > > > > > > > > > 5 files changed, 267 insertions(+)
> > > > > > > > > > > create mode 100644 drivers/video/hdmi-notifier.c
> > > > > > > > > > > create mode 100644 include/linux/hdmi-notifier.h
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > > > > > > > index 5cfbea4ce575..ffb7376f9509 100644
> > > > > > > > > > > --- a/MAINTAINERS
> > > > > > > > > > > +++ b/MAINTAINERS
> > > > > > > > > > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> > > > > > > > > > > S: Maintained
> > > > > > > > > > > F: drivers/media/platform/vicodec/*
> > > > > > > > > > >
> > > > > > > > > > > +VIDEO FRAMEWORK
> > > > > > > > > > > +M: Hans Verkuil <hverkuil@xs4all.nl>
> > > > > > > > > > > +L: linux-media@vger.kernel.org
> > > > > > > > > > > +F: drivers/video/hdmi-notifier.*
> > > > > > > > > > > +S: Maintained
> > > > > > > > > > > +
> > > > > > > > > > > VIDEO MULTIPLEXER DRIVER
> > > > > > > > > > > M: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > L: linux-media@vger.kernel.org
> > > > > > > > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > > > > > > > > index 83d3d271ca15..000ba9bc0ae7 100644
> > > > > > > > > > > --- a/drivers/video/Kconfig
> > > > > > > > > > > +++ b/drivers/video/Kconfig
> > > > > > > > > > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> > > > > > > > > > > config HDMI
> > > > > > > > > > > bool
> > > > > > > > > > >
> > > > > > > > > > > +config HDMI_NOTIFIERS
> > > > > > > > > > > + bool
> > > > > > > > > > > +
> > > > > > > > > > > endif # HAS_IOMEM
> > > > > > > > > > >
> > > > > > > > > > > if VT
> > > > > > > > > > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > > > > > > > > > index df7650adede9..eff4736102ca 100644
> > > > > > > > > > > --- a/drivers/video/Makefile
> > > > > > > > > > > +++ b/drivers/video/Makefile
> > > > > > > > > > > @@ -1,6 +1,7 @@
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > obj-$(CONFIG_VGASTATE) += vgastate.o
> > > > > > > > > > > obj-$(CONFIG_HDMI) += hdmi.o
> > > > > > > > > > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_VT) += console/
> > > > > > > > > > > obj-$(CONFIG_FB_STI) += console/
> > > > > > > > > > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..d1eedf661648
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > @@ -0,0 +1,145 @@
> > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/export.h>
> > > > > > > > > > > +#include <linux/hdmi-notifier.h>
> > > > > > > > > > > +#include <linux/string.h>
> > > > > > > > > > > +#include <linux/slab.h>
> > > > > > > > > > > +#include <linux/list.h>
> > > > > > > > > > > +
> > > > > > > > > > > +static LIST_HEAD(hdmi_notifiers);
> > > > > > > > > > > +static DEFINE_MUTEX(hdmi_notifiers_lock);
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n;
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_for_each_entry(n, &hdmi_notifiers, head) {
> > > > > > > > > > > + if (n->dev == dev) {
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + return n;
> > > > > > > > > > > + }
> > > > > > > > > > > + }
> > > > > > > > > > > + n = kzalloc(sizeof(*n), GFP_KERNEL);
> > > > > > > > > > > + if (!n)
> > > > > > > > > > > + goto unlock;
> > > > > > > > > > > + n->dev = dev;
> > > > > > > > > > > + mutex_init(&n->lock);
> > > > > > > > > > > + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> > > > > > > > > > > + kref_init(&n->kref);
> > > > > > > > > > > + list_add_tail(&n->head, &hdmi_notifiers);
> > > > > > > > > > > +unlock:
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + return n;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> > > > > > > > > > > +
> > > > > > > > > > > +static void hdmi_notifier_release(struct kref *kref)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n =
> > > > > > > > > > > + container_of(kref, struct hdmi_notifier, kref);
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_del(&n->head);
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + kfree(n);
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + kref_put(&n->kref, hdmi_notifier_release);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->connected) {
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + if (n->edid_size)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_EDID, n);
> > > > > > > > > > > + if (n->has_eld)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_ELD, n);
> > > > > > > > > > > + }
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret == 0)
> > > > > > > > > > > + hdmi_notifier_put(n);
> > > > > > > > > > > + return ret;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = false;
> > > > > > > > > > > + n->has_eld = false;
> > > > > > > > > > > + n->edid_size = 0;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->edid_allocated_size < size) {
> > > > > > > > > > > + void *p = kmalloc(size, GFP_KERNEL);
> > > > > > > > > > > +
> > > > > > > > > > > + if (!p) {
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return -ENOMEM;
> > > > > > > > > > > + }
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + n->edid = p;
> > > > > > > > > > > + n->edid_allocated_size = size;
> > > > > > > > > > > + }
> > > > > > > > > > > + memcpy(n->edid, edid, size);
> > > > > > > > > > > + n->edid_size = size;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128])
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + memcpy(n->eld, eld, sizeof(n->eld));
> > > > > > > > > > > + n->has_eld = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> > > > > > > > > > > diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..c8f35110e3e3
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/include/linux/hdmi-notifier.h
> > > > > > > > > > > @@ -0,0 +1,112 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > + * hdmi-notifier.h - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +#define LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/types.h>
> > > > > > > > > > > +#include <linux/notifier.h>
> > > > > > > > > > > +#include <linux/kref.h>
> > > > > > > > > > > +
> > > > > > > > > > > +enum {
> > > > > > > > > > > + HDMI_CONNECTED,
> > > > > > > > > > > + HDMI_DISCONNECTED,
> > > > > > > > > > > + HDMI_NEW_EDID,
> > > > > > > > > > > + HDMI_NEW_ELD,
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +struct device;
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier {
> > > > > > > > > > > + /* Lock to protect callback registration and notification. */
> > > > > > > > > > > + struct mutex lock;
> > > > > > > > > > > + struct list_head head;
> > > > > > > > > > > + struct kref kref;
> > > > > > > > > > > + struct blocking_notifier_head notifiers;
> > > > > > > > > > > + struct device *dev;
> > > > > > > > > > > +
> > > > > > > > > > > + /* Current state */
> > > > > > > > > > > + unsigned int connected : 1;
> > > > > > > > > > > + unsigned int has_eld : 1;
> > > > > > > > > > > + unsigned char eld[128];
> > > > > > > > > > > + void *edid;
> > > > > > > > > > > + size_t edid_size;
> > > > > > > > > > > + size_t edid_allocated_size;
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_get - find or create a new hdmi_notifier for the given device.
> > > > > > > > > > > + * @dev: device that sends the events.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If a notifier for device @dev already exists, then increase the refcount
> > > > > > > > > > > + * and return that notifier.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If it doesn't exist, then allocate a new notifier struct and return a
> > > > > > > > > > > + * pointer to that new struct.
> > > > > > > > > > > + *
> > > > > > > > > > > + * Return NULL if the memory could not be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_put - decrease refcount and delete when the refcount reaches 0.
> > > > > > > > > > > + * @n: notifier
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_register - register the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_unregister - unregister the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n,
> > > > > > > > > > > + struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_connect - send a connect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_CONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_disconnect - send a disconnect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_DISCONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_edid - send a new EDID event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_EDID event to any registered parties.
> > > > > > > > > > > + * This function will make a copy the EDID so it can return -ENOMEM if
> > > > > > > > > > > + * no memory could be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_eld - send a new ELD event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_ELD event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128]);
> > > > > > > > > > > +
> > > > > > > > > > > +#endif
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Vetter
> > > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > > http://blog.ffwll.ch
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Vetter
> > > > > > > Software Engineer, Intel Corporation
> > > > > > > http://blog.ffwll.ch
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/7] video: add HDMI state notifier support
From: Cheng-yi Chiang @ 2019-06-20 13:23 UTC (permalink / raw)
To: Cheng-yi Chiang, Hans Verkuil, linux-kernel,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Philipp Zabel,
Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Russell King, Andrzej Hajda, Laurent Pinchart, David Airlie,
Rob Herring, Heiko Stuebner, Doug Anderson, Dylan Reid,
tzungbi-F7+t8E8rja9g9hUCZPvPmw,
linux-media-u79uwXL29TY76Z2rM5mHXA,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
dri-devel-PD4FTy7X32k
Cc: Daniel Vetter
In-Reply-To: <20190620092506.GP12905-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org>
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> wrote:
>
> On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> wrote:
> > >
> > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> wrote:
> > > > >
> > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > > > > > > > > > From: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> > > > > > > > > > >
> > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > > > > > > > > > information from HDMI drivers to their CEC and audio counterparts.
> > > > > > > > > > >
> > > > > > > > > > > Based on an earlier version from Russell King:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/
> > > > > > > > > > >
> > > > > > > > > > > The hdmi_notifier is a reference counted object containing the HDMI state
> > > > > > > > > > > of an HDMI device.
> > > > > > > > > > >
> > > > > > > > > > > When a new notifier is registered the current state will be reported to
> > > > > > > > > > > that notifier at registration time.
> > > > > > > > > > >
> > > > > > > > > > > Based on Hans Verkuil's patch:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/
> > > > > > > > > >
> > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific notifier
> > > > > > > > > > found in drivers/media/cec/cec-notifier.c?
> > > > > > > > > >
> > > > > > > > > > I don't think it makes sense to have two notifier implementations in the kernel.
> > > > > > > > > > The original intention was to have the notifier deal with both CEC and ASoC
> > > > > > > > > > notifications, but there was not enough interest for the ASoC bits at the time
> > > > > > > > > > and it was dropped.
> > > > > > > > > >
> > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on that this
> > > > > > > > > > week. I'll CC you when I post those. Those might be a good starting point
> > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally intended.
> > > > > > > > > >
> > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
> > > > > > > > > > working on some nice cec-notifier improvements as well.
> > > > > > > > >
> > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi
> > > > > > > > > already in drm/drm_audio_component.h, but it's not used by anything
> > > > > > > > > outside of i915. Imo we should extend that, not reinvent a new wheel.
> > > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it is
> > > > > > > > specific to HDA.
> > > > > > > > I am not familiar with drm and HDA. I am not sure how applicable it
> > > > > > > > would be to report jack status to ASoC.
> > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
> > > > > > > > should be possible.
> > > > > > >
> > > > > > > Currently hda is the only user, but the idea was to make it more generic.
> > > > > > > Jack status in alsa is what drm calls connector status btw.
> > > > > > >
> > > > > > > So if we can take that as a baseline and extend it (probably needs some
> > > > > > > registration boilerplate and helpers to look up the right endpoint using
> > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), that
> > > > > > > would be great I think.
> > > > > > >
> > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for one
> > > > > > > > > case, as soon as you have multiple devices and need to make sure you get
> > > > > > > > > the update for the right one it all comes crashing down. Please create an
> > > > > > > > > api which registers for updates from a specific device only, plus
> > > > > > > > > something that has real callbacks (like the drm_audio_component.h thing we
> > > > > > > > > started already).
> > > > > > > >
> > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a
> > > > > > > > specific device only.
> > > > > > > > hdmi_notifier_get takes a device and return the notifier.
> > > > > > >
> > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier
> > > > > > > concerns addressed.
> > > > > > >
> > > > > > > > It seems that a major difference between drm_audio_components and
> > > > > > > > hdmi-notifier is that
> > > > > > > > drm_audio_components defines all supported ops in drm_audio_component_audio_ops.
> > > > > > > > On the other hand, hdmi-notifier passes different events using an enum
> > > > > > > > like HDMI_CONNECTED and let listener handle different events.
> > > > > > > > In this regard I agree with you that drm_audio_component is cleaner.
> > > > > > > > Anyway, I will look into it a bit more and see how it works.
> > > > > > >
> > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for
> > > > > > > registration, some _ops structure for the actual notifications, then
> > > > > > > there's a solid interface. I just really don't like the opaque void *
> > > > > > > interface notifier provides, it encourages abuse way too much.
> > > > > > >
> > > > > > > Ofc the registration side would then no longer be based on the notifier
> > > > > > > datastructure, list_head (like cec-notifier.c) of registeres devices with
> > > > > > > their _ops structure should be enough.
> > > > > > > -Daniel
> > > > > >
> > > > > > Hi Daniel,
> > > > > > Yes, I agree the above statement that we should have a more solid interface.
> > > > > >
> > > > > > Hi Hans,
> > > > > > I am not sure if I missed the patch.
> > > > > > Do you have a estimated timeline for new cec-notifier interface you
> > > > > > are working on?
> > > > > > It seems that your PoC patch needs Dariusz's patch to work.
> > > > > > I would like to seek your advice on whether I can proceed without your
> > > > > > patch and Dariusz's patch.
> > > > > >
> > > > > > I looked through the patch from Dariusz
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/21/389
> > > > > >
> > > > > > , and saw that you were thinking whether we should use cec-notifier
> > > > > > for both HDMI and CEC.
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/24/298
> > > > > >
> > > > > > Could you please let me know your latest thought on whether we should
> > > > > > reuse cec-notifier?
> > > > >
> > > > > Nah, see later in that thread, I think cec and audio seem to be different
> > > > > use-cases.
> > > > >
> > > > Ack
> > > > > But definitely a good idea to sync with Dariusz, I forgot to pull the two
> > > > > threads together. Thanks for doing that.
> > > > >
> > > > > > I agree with you that I should not proceed with hdmi-notifier. Reasons include:
> > > > > > 1. Method like cec_notifier_parse_hdmi_phandle can be reused. It is
> > > > > > error prone to memory leak if it is implemented by user, like the
> > > > > > patch in hdmi-codec.c in this series did not handle the ref count.
> > > > > > 2. cec-notifier has a simpler implementation of register / unregister
> > > > > > because there is no call chain. I am not aware of the need for
> > > > > > hdmi-notifier to support a chain of callbacks. So I think that call
> > > > > > chain support can be removed.
> > > > > >
> > > > > > If I go ahead and add a new interface to register ops to handle
> > > > > > connector status report from cec-notifer, based on current
> > > > > > cec-notifier, do you think that would work ?
> > > > > > I think it might work if I add another cec_notifier object inside
> > > > > > dw-hdmi.c, but only for HDMI jack reporting, not for CEC related
> > > > > > reporting.
> > > > > >
> > > > > > And after some investigation, I realize that my requirement is even
> > > > > > simpler. I don't need hdmi_event_new_edid and hdmi_event_new_eld in my
> > > > > > use case.
> > > > >
> > > > > Yeah, connector status is how we started with the drm/alsa interface in
> > > > > i915 too, but later on had to extend it. I think eventually we'll need it
> > > > > all, that's why I suggested to use that as the interface between drm and
> > > > > alsa side, but augmented with some register/unregister and bind logic.
> > > > >
> > > > Hi Daniel,
> > > > Sorry for the late reply.
> > > > I spent some time investigating how drm_audio_component works.
> > > > The coupling of HDA in drm_audio_component framework makes the
> > > > register/unregister logic looks complicated to me as I don't use HDA
> > > > in my use case.
> > > > After some time, I found another patch series which also use component
> > > > framework to communicate between drm and mei world.
> > > >
> > > > https://patchwork.kernel.org/patch/10824527/
> > > >
> > > > And from that patch, I realized that I can follow the similar approach
> > > > to register a master component on ALSA side, a slave component on DRM
> > > > side, and use device and subcomponent to match them.
> > >
> > > Sorry for the confusion here. My suggestion is _not_ to use the component
> > > framework. That's only meant for one-off special case solutions. For that
> > > part I think you need to build a new register/unregister/bind/unbind
> > > infrastructure, like we have for lots of other things in the kernel
> > > already (clocks, gpio, drm_panel, drm_bridge as just a few examples).
> > >
> >
> > Hi Daniel,
> > Thank you for the prompt reply and guidance.
> >
> > I see. I was not aware that we should avoid using component framework.
> > Your example of drm_panel seems great.
> > I plan is to reuse drm_audio_components like this:
> > A LIST_HEAD holding the list of drm_audio_components instances, and add API
> > drm_audio_comp_init,
> > _add, _remove, _attach, _detach.
> > And for DRM side to look up the instance to use, we can use similar
> > approach like of_drm_find_panel, that is, using device tree node.
>
> Sounds good. I guess somewhere in there you'll use of_node/DT information
> to make sure you have the right audio component? Just to make sure we're
> agreeing on the design completely.
ACK.
I need to check closer. I will use of_node/DT information,
but it might be the other way around as machine driver can get the
hdmi node and hence hdmi device,
and that device can be passed to codec driver to register a component
with the device.
So the register mechanism is more like original hdmi_notifier.
>
>
> > > My suggestion with the i915/hda interface is to build on the actual
> > > interface for signalling connector status and exchanging eld and stuff
> > > like that.
> > >
> >
> > I agree with using this interface. But in my use case there is no much
> > data to be exchanged.
> > Only the connector status needs to be passed from DRM to ALSA world.
> > If in the future there is need for ALSA to make some call, that ops
> > can be added to drm_audio_component_ops.
>
> Yeah I think it's ok to not implement everyhing. Iirc we started with only
> the connector status too, then extended that to sharing the eld.
>
> There's also some i915/had hacks (clocks without using clock framework,
> power domains without using power framework), where for DT platforms we
> probably want to do this right.
>
> Looking at the entire thing we might need to create new _ops structures,
> or at least refactor them quite a bit. But we can improve things
> iteratively imo.
ACK
>
>
> > > > I should be able to do this without touching anything specific to HDA.
> > > > After that, DRM world should be able to use the ops in
> > > > drm_audio_component_audio_ops to notify ALSA world some event when
> > > > there is something happen in DRM world.
> > > > Currently the ops like pin_eld_notify, pin2port are too specific to HDA.
> > > > I think I can add an ops to drm_audio_component_audio_ops to convey
> > > > connector status.
> > >
> > > Hm why? The pin2port is maybe not the best one, since port is an intel
> > > construct, and pin a hda construct. So we'd need to change those to talk
> > > in terms of the higher-level concepts (alsa output pin and drm crtc
> > > probably).
> > >
> >
> > I took more look into how information of audio being present or not is
> > passed between DRM and ALSA world,
> > taking drivers/gpu/drm/i915/intel_audio.c and
> > sound/soc/codecs/hdac_hdmi.c as example.
> > I see the sequence is DRM side to call pin_eld_notify ops with port
> > and pipe to ALSA side.
> > Then, ALSA side calls get_eld ops with port and pipe to look up
> > whether the saved encoder has audio_connector.
> >
> > However, my use case on RK3288 is different in that ALSA side does not
> > need to get ELD.
> > I think adding an ops like connector_status() for DRM side to call in
> > parallel to pin_eld_notify is reasonable.
> > Both DRM side and ALSA side can choose what is the desired ops to be
> > implemented as these ops can be optional.
>
> I think pin_eld_notify and get_eld are just mislabeled, they give you both
> eld and status (the bool *enabled in get_eld). Maybe we should rename them
> to get_status and pin_status_notify?
ACK
>
> > > The other stuff should work a bit better. Either way my idea was to evolve
> > > that interface (and put in the place the required type-casting for
> > > i915/hda), since more users increases the odds that it actually is a good
> > > design.
> > >
> > Sorry I don't understand this part.
> > Could you please elaborate more about type-casting for i915/hda ?
> >
> > TBH, If possible, I would like to minimize the change I'll need to
> > make to i915/hda because of my limited knowledge of i915/hda and my
> > limited bandwidth.
> >
> > I would like to point out the scope of this problem to help the discussion.
> > I think this is a common need on boards using ALSA hdmi-codec driver.
> > Currently, there are many DRM drivers resorted to hdmi_codec_ops
> > approach to let ALSA world talks to DRM world.
> > That hdmi_codec_ops approach came around 2016 so it was before
> > drm_audio_component was introduced.
> > As for how jack status is reported for these boards, I am not sure,
> > maybe with local patches of hdmi-notifier.
> > So this is not a one-off change for RK3288 only. I believe other
> > boards will benefit from this jack reporting feature as well.
> >
> > As for extending and improving the interface of drm_audio_component so
> > more users can adopt it,
> > I think the ops in hdmi_codec_ops are good candidates to be moved to
> > drm_audio_component to consolidate the interface between DRM and ALSA
> > better.
> > That said, I don't feel a strong need to change i915/hda if the
> > purpose is to let more users use drm_audio_component.
> >
> > I can drew these changes in three stages:
> > 1. Add the infrastructure to add/remove/attach/detach
> > drm_audio_component (like how drm_panel does), and add
> > connector_status ops.
> > 2. Move ops in hdmi_codec_ops into drm_audio_components.
> > 3. Desired change of i915/hda (I am not clear about this part)
> >
> > I can help with 1 and 2 as Chromium tree have at least RK3288 and
> > MT8173 SoC using hdmi-codec driver so it is easier for me to try
> > patches.
> > And there may be more in the future.
> >
> > Thanks again for the patience.
> > I am not familiar with DRM so it takes me more time to digest your
> > comment and reply.
>
> Hm sorry, I totally forgot about this again, iirc I looked at this.
>
> Yeah fully agreeing that hdmi_audio_code is probably a better starting
> point. Problem is that becuase hdmi_codec is built on top of platform
> device it's quite a bit harder to extend with callbacks and things like
> that, without breaking the driver model.
>
> I need to think about this more, but if all we need to look at is
> hdmi_codec, then I think this becomes a lot easier. And we can ignore
> drm_audio_component.h completely.
It is surprising that you think this way.
Maybe the original patch before hdmi-notifier was introduced is the
better way to solve this issue, if we only need to look at hdmi_codec.
The history of hdmi_codec driver is in this patch series:
https://lore.kernel.org/patchwork/patch/539656/
There was a callback mechanism implemented between dw-hdmi and hdmi
codec driver.
It was later consolidated by Doug in this patch for better jack status
reporting:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/
I am not sure why the original patch series did not get fully accepted
in the upstream.
It was quite long time ago.
But if you think this might be the right way to do, then it is even
better for us because the patch series and Doug's patch had been quite
stable
on our RK3288 products for about four years with plenty of users, so
we have much higher confidence in them.
I can rebase and clean up them and post another patch for review.
Please let me know what approach you feel is better.
Thanks again!
>
> -Daniel
>
>
> >
> > > > I will work toward this approach these days.
> > > > If you have other thought please let me know.
> > > > Thanks!
> > > >
> > > > > > I just need to report the connector status from synopsys/dw-hdmi.c to
> > > > > > codecs/hdmi-codec.c for codec driver to update the jack status.
> > > > > > Do you think I can proceed in this direction ? Or do you prefer I wait
> > > > > > for a while and work on it based on your new patch.
> > > > >
> > > > > I think most important part here is that we sync across all the different
> > > > > people pushing for better drm/alsa integration. What the solution looks
> > > > > like in the end doesn't matter much imo, as long as we don't end up with 3
> > > > > different things :-)
> > > >
> > > > Totally agree.
> > >
> > > Anyway just my thoughts, let's keep chatting.
> > >
> > > Cheers, Daniel
> > >
> > > > Thanks again!
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > >
> > > > > > Thanks a lot!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks again!
> > > > > > > >
> > > > > > > > > -Daniel
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Hans
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Modified by Cheng-Yi Chiang:
> > > > > > > > > > > - Add a section in MAINTAINER.
> > > > > > > > > > > - Changes connected and has_eld to bitfield of unsigned int.
> > > > > > > > > > > - Other minor fixes to pass checkpatch.pl --strict checks.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
> > > > > > > > > > > Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > > > > > > > > > > Signed-off-by: Cheng-Yi Chiang <cychiang-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > > > > > > > > > > ---
> > > > > > > > > > > The original patch is at
> > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org
> > > > > > > > > > >
> > > > > > > > > > > MAINTAINERS | 6 ++
> > > > > > > > > > > drivers/video/Kconfig | 3 +
> > > > > > > > > > > drivers/video/Makefile | 1 +
> > > > > > > > > > > drivers/video/hdmi-notifier.c | 145 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > include/linux/hdmi-notifier.h | 112 ++++++++++++++++++++++++++
> > > > > > > > > > > 5 files changed, 267 insertions(+)
> > > > > > > > > > > create mode 100644 drivers/video/hdmi-notifier.c
> > > > > > > > > > > create mode 100644 include/linux/hdmi-notifier.h
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > > > > > > > index 5cfbea4ce575..ffb7376f9509 100644
> > > > > > > > > > > --- a/MAINTAINERS
> > > > > > > > > > > +++ b/MAINTAINERS
> > > > > > > > > > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> > > > > > > > > > > S: Maintained
> > > > > > > > > > > F: drivers/media/platform/vicodec/*
> > > > > > > > > > >
> > > > > > > > > > > +VIDEO FRAMEWORK
> > > > > > > > > > > +M: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
> > > > > > > > > > > +L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > > > > > > > > > +F: drivers/video/hdmi-notifier.*
> > > > > > > > > > > +S: Maintained
> > > > > > > > > > > +
> > > > > > > > > > > VIDEO MULTIPLEXER DRIVER
> > > > > > > > > > > M: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > > > > > > > > > > L: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > > > > > > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > > > > > > > > index 83d3d271ca15..000ba9bc0ae7 100644
> > > > > > > > > > > --- a/drivers/video/Kconfig
> > > > > > > > > > > +++ b/drivers/video/Kconfig
> > > > > > > > > > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> > > > > > > > > > > config HDMI
> > > > > > > > > > > bool
> > > > > > > > > > >
> > > > > > > > > > > +config HDMI_NOTIFIERS
> > > > > > > > > > > + bool
> > > > > > > > > > > +
> > > > > > > > > > > endif # HAS_IOMEM
> > > > > > > > > > >
> > > > > > > > > > > if VT
> > > > > > > > > > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > > > > > > > > > index df7650adede9..eff4736102ca 100644
> > > > > > > > > > > --- a/drivers/video/Makefile
> > > > > > > > > > > +++ b/drivers/video/Makefile
> > > > > > > > > > > @@ -1,6 +1,7 @@
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > obj-$(CONFIG_VGASTATE) += vgastate.o
> > > > > > > > > > > obj-$(CONFIG_HDMI) += hdmi.o
> > > > > > > > > > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_VT) += console/
> > > > > > > > > > > obj-$(CONFIG_FB_STI) += console/
> > > > > > > > > > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..d1eedf661648
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > @@ -0,0 +1,145 @@
> > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/export.h>
> > > > > > > > > > > +#include <linux/hdmi-notifier.h>
> > > > > > > > > > > +#include <linux/string.h>
> > > > > > > > > > > +#include <linux/slab.h>
> > > > > > > > > > > +#include <linux/list.h>
> > > > > > > > > > > +
> > > > > > > > > > > +static LIST_HEAD(hdmi_notifiers);
> > > > > > > > > > > +static DEFINE_MUTEX(hdmi_notifiers_lock);
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n;
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_for_each_entry(n, &hdmi_notifiers, head) {
> > > > > > > > > > > + if (n->dev == dev) {
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + return n;
> > > > > > > > > > > + }
> > > > > > > > > > > + }
> > > > > > > > > > > + n = kzalloc(sizeof(*n), GFP_KERNEL);
> > > > > > > > > > > + if (!n)
> > > > > > > > > > > + goto unlock;
> > > > > > > > > > > + n->dev = dev;
> > > > > > > > > > > + mutex_init(&n->lock);
> > > > > > > > > > > + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> > > > > > > > > > > + kref_init(&n->kref);
> > > > > > > > > > > + list_add_tail(&n->head, &hdmi_notifiers);
> > > > > > > > > > > +unlock:
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + return n;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> > > > > > > > > > > +
> > > > > > > > > > > +static void hdmi_notifier_release(struct kref *kref)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n =
> > > > > > > > > > > + container_of(kref, struct hdmi_notifier, kref);
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_del(&n->head);
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + kfree(n);
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + kref_put(&n->kref, hdmi_notifier_release);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->connected) {
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + if (n->edid_size)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_EDID, n);
> > > > > > > > > > > + if (n->has_eld)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_ELD, n);
> > > > > > > > > > > + }
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret == 0)
> > > > > > > > > > > + hdmi_notifier_put(n);
> > > > > > > > > > > + return ret;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = false;
> > > > > > > > > > > + n->has_eld = false;
> > > > > > > > > > > + n->edid_size = 0;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->edid_allocated_size < size) {
> > > > > > > > > > > + void *p = kmalloc(size, GFP_KERNEL);
> > > > > > > > > > > +
> > > > > > > > > > > + if (!p) {
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return -ENOMEM;
> > > > > > > > > > > + }
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + n->edid = p;
> > > > > > > > > > > + n->edid_allocated_size = size;
> > > > > > > > > > > + }
> > > > > > > > > > > + memcpy(n->edid, edid, size);
> > > > > > > > > > > + n->edid_size = size;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128])
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + memcpy(n->eld, eld, sizeof(n->eld));
> > > > > > > > > > > + n->has_eld = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> > > > > > > > > > > diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..c8f35110e3e3
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/include/linux/hdmi-notifier.h
> > > > > > > > > > > @@ -0,0 +1,112 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > + * hdmi-notifier.h - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +#define LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/types.h>
> > > > > > > > > > > +#include <linux/notifier.h>
> > > > > > > > > > > +#include <linux/kref.h>
> > > > > > > > > > > +
> > > > > > > > > > > +enum {
> > > > > > > > > > > + HDMI_CONNECTED,
> > > > > > > > > > > + HDMI_DISCONNECTED,
> > > > > > > > > > > + HDMI_NEW_EDID,
> > > > > > > > > > > + HDMI_NEW_ELD,
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +struct device;
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier {
> > > > > > > > > > > + /* Lock to protect callback registration and notification. */
> > > > > > > > > > > + struct mutex lock;
> > > > > > > > > > > + struct list_head head;
> > > > > > > > > > > + struct kref kref;
> > > > > > > > > > > + struct blocking_notifier_head notifiers;
> > > > > > > > > > > + struct device *dev;
> > > > > > > > > > > +
> > > > > > > > > > > + /* Current state */
> > > > > > > > > > > + unsigned int connected : 1;
> > > > > > > > > > > + unsigned int has_eld : 1;
> > > > > > > > > > > + unsigned char eld[128];
> > > > > > > > > > > + void *edid;
> > > > > > > > > > > + size_t edid_size;
> > > > > > > > > > > + size_t edid_allocated_size;
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_get - find or create a new hdmi_notifier for the given device.
> > > > > > > > > > > + * @dev: device that sends the events.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If a notifier for device @dev already exists, then increase the refcount
> > > > > > > > > > > + * and return that notifier.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If it doesn't exist, then allocate a new notifier struct and return a
> > > > > > > > > > > + * pointer to that new struct.
> > > > > > > > > > > + *
> > > > > > > > > > > + * Return NULL if the memory could not be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_put - decrease refcount and delete when the refcount reaches 0.
> > > > > > > > > > > + * @n: notifier
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_register - register the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_unregister - unregister the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n,
> > > > > > > > > > > + struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_connect - send a connect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_CONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_disconnect - send a disconnect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_DISCONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_edid - send a new EDID event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_EDID event to any registered parties.
> > > > > > > > > > > + * This function will make a copy the EDID so it can return -ENOMEM if
> > > > > > > > > > > + * no memory could be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_eld - send a new ELD event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_ELD event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128]);
> > > > > > > > > > > +
> > > > > > > > > > > +#endif
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Vetter
> > > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > > http://blog.ffwll.ch
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Vetter
> > > > > > > Software Engineer, Intel Corporation
> > > > > > > http://blog.ffwll.ch
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 1/7] video: add HDMI state notifier support
From: Cheng-yi Chiang @ 2019-06-20 13:23 UTC (permalink / raw)
To: Cheng-yi Chiang, Hans Verkuil, linux-kernel,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman, Philipp Zabel,
Mark Brown, Liam Girdwood, Takashi Iwai, Jaroslav Kysela,
Russell King, Andrzej Hajda, Laurent Pinchart, David Airlie,
Rob Herring, Heiko Stuebner, Doug Anderson, Dylan Reid, tzungbi,
linux-media,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
dri-devel
Cc: Daniel Vetter
In-Reply-To: <20190620092506.GP12905@phenom.ffwll.local>
On Thu, Jun 20, 2019 at 5:25 PM Daniel Vetter <daniel@ffwll.ch> wrote:
>
> On Wed, Jun 19, 2019 at 07:48:11PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > >
> > > > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > > > On Tue, Jun 4, 2019 at 3:24 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > >
> > > > > > > On Tue, Jun 04, 2019 at 10:32:50AM +0800, Cheng-yi Chiang wrote:
> > > > > > > > On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter <daniel@ffwll.ch> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > > > > > > > > > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > > > > > > > > > From: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > >
> > > > > > > > > > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > > > > > > > > > information from HDMI drivers to their CEC and audio counterparts.
> > > > > > > > > > >
> > > > > > > > > > > Based on an earlier version from Russell King:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9277043/
> > > > > > > > > > >
> > > > > > > > > > > The hdmi_notifier is a reference counted object containing the HDMI state
> > > > > > > > > > > of an HDMI device.
> > > > > > > > > > >
> > > > > > > > > > > When a new notifier is registered the current state will be reported to
> > > > > > > > > > > that notifier at registration time.
> > > > > > > > > > >
> > > > > > > > > > > Based on Hans Verkuil's patch:
> > > > > > > > > > >
> > > > > > > > > > > https://patchwork.kernel.org/patch/9472521/
> > > > > > > > > >
> > > > > > > > > > Erm, you are aware that this patch morphed into a CEC-specific notifier
> > > > > > > > > > found in drivers/media/cec/cec-notifier.c?
> > > > > > > > > >
> > > > > > > > > > I don't think it makes sense to have two notifier implementations in the kernel.
> > > > > > > > > > The original intention was to have the notifier deal with both CEC and ASoC
> > > > > > > > > > notifications, but there was not enough interest for the ASoC bits at the time
> > > > > > > > > > and it was dropped.
> > > > > > > > > >
> > > > > > > > > > I am planning changes to the cec-notifier API, I hope to work on that this
> > > > > > > > > > week. I'll CC you when I post those. Those might be a good starting point
> > > > > > > > > > to convert the cec-notifier to an hdmi-notifier as was originally intended.
> > > > > > > > > >
> > > > > > > > > > I've added your colleague Dariusz Marcinkiewicz to the CC list since he's been
> > > > > > > > > > working on some nice cec-notifier improvements as well.
> > > > > > > > >
> > > > > > > > > We also have some interfaces for drm/alsa interactions around hdmi
> > > > > > > > > already in drm/drm_audio_component.h, but it's not used by anything
> > > > > > > > > outside of i915. Imo we should extend that, not reinvent a new wheel.
> > > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > > Thank you for the pointer. Looking at the ops, it seems that it is
> > > > > > > > specific to HDA.
> > > > > > > > I am not familiar with drm and HDA. I am not sure how applicable it
> > > > > > > > would be to report jack status to ASoC.
> > > > > > > > There is a use case in sound/soc/codecs/hdac_hdmi.c though so it
> > > > > > > > should be possible.
> > > > > > >
> > > > > > > Currently hda is the only user, but the idea was to make it more generic.
> > > > > > > Jack status in alsa is what drm calls connector status btw.
> > > > > > >
> > > > > > > So if we can take that as a baseline and extend it (probably needs some
> > > > > > > registration boilerplate and helpers to look up the right endpoint using
> > > > > > > of/dt for soc systems, we use component.c in i915/hda for this), that
> > > > > > > would be great I think.
> > > > > > >
> > > > > > > > > Another note: notifiers considered evil, imo. Gets the job done for one
> > > > > > > > > case, as soon as you have multiple devices and need to make sure you get
> > > > > > > > > the update for the right one it all comes crashing down. Please create an
> > > > > > > > > api which registers for updates from a specific device only, plus
> > > > > > > > > something that has real callbacks (like the drm_audio_component.h thing we
> > > > > > > > > started already).
> > > > > > > >
> > > > > > > > To clarify a bit, this hdmi-notifier indeed supports updating from a
> > > > > > > > specific device only.
> > > > > > > > hdmi_notifier_get takes a device and return the notifier.
> > > > > > >
> > > > > > > Hm I missed that, I thought it's global, so one of my usual notifier
> > > > > > > concerns addressed.
> > > > > > >
> > > > > > > > It seems that a major difference between drm_audio_components and
> > > > > > > > hdmi-notifier is that
> > > > > > > > drm_audio_components defines all supported ops in drm_audio_component_audio_ops.
> > > > > > > > On the other hand, hdmi-notifier passes different events using an enum
> > > > > > > > like HDMI_CONNECTED and let listener handle different events.
> > > > > > > > In this regard I agree with you that drm_audio_component is cleaner.
> > > > > > > > Anyway, I will look into it a bit more and see how it works.
> > > > > > >
> > > > > > > Yeah I think if we could combine the approach, i.e. notifier side for
> > > > > > > registration, some _ops structure for the actual notifications, then
> > > > > > > there's a solid interface. I just really don't like the opaque void *
> > > > > > > interface notifier provides, it encourages abuse way too much.
> > > > > > >
> > > > > > > Ofc the registration side would then no longer be based on the notifier
> > > > > > > datastructure, list_head (like cec-notifier.c) of registeres devices with
> > > > > > > their _ops structure should be enough.
> > > > > > > -Daniel
> > > > > >
> > > > > > Hi Daniel,
> > > > > > Yes, I agree the above statement that we should have a more solid interface.
> > > > > >
> > > > > > Hi Hans,
> > > > > > I am not sure if I missed the patch.
> > > > > > Do you have a estimated timeline for new cec-notifier interface you
> > > > > > are working on?
> > > > > > It seems that your PoC patch needs Dariusz's patch to work.
> > > > > > I would like to seek your advice on whether I can proceed without your
> > > > > > patch and Dariusz's patch.
> > > > > >
> > > > > > I looked through the patch from Dariusz
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/21/389
> > > > > >
> > > > > > , and saw that you were thinking whether we should use cec-notifier
> > > > > > for both HDMI and CEC.
> > > > > >
> > > > > > https://lkml.org/lkml/2019/5/24/298
> > > > > >
> > > > > > Could you please let me know your latest thought on whether we should
> > > > > > reuse cec-notifier?
> > > > >
> > > > > Nah, see later in that thread, I think cec and audio seem to be different
> > > > > use-cases.
> > > > >
> > > > Ack
> > > > > But definitely a good idea to sync with Dariusz, I forgot to pull the two
> > > > > threads together. Thanks for doing that.
> > > > >
> > > > > > I agree with you that I should not proceed with hdmi-notifier. Reasons include:
> > > > > > 1. Method like cec_notifier_parse_hdmi_phandle can be reused. It is
> > > > > > error prone to memory leak if it is implemented by user, like the
> > > > > > patch in hdmi-codec.c in this series did not handle the ref count.
> > > > > > 2. cec-notifier has a simpler implementation of register / unregister
> > > > > > because there is no call chain. I am not aware of the need for
> > > > > > hdmi-notifier to support a chain of callbacks. So I think that call
> > > > > > chain support can be removed.
> > > > > >
> > > > > > If I go ahead and add a new interface to register ops to handle
> > > > > > connector status report from cec-notifer, based on current
> > > > > > cec-notifier, do you think that would work ?
> > > > > > I think it might work if I add another cec_notifier object inside
> > > > > > dw-hdmi.c, but only for HDMI jack reporting, not for CEC related
> > > > > > reporting.
> > > > > >
> > > > > > And after some investigation, I realize that my requirement is even
> > > > > > simpler. I don't need hdmi_event_new_edid and hdmi_event_new_eld in my
> > > > > > use case.
> > > > >
> > > > > Yeah, connector status is how we started with the drm/alsa interface in
> > > > > i915 too, but later on had to extend it. I think eventually we'll need it
> > > > > all, that's why I suggested to use that as the interface between drm and
> > > > > alsa side, but augmented with some register/unregister and bind logic.
> > > > >
> > > > Hi Daniel,
> > > > Sorry for the late reply.
> > > > I spent some time investigating how drm_audio_component works.
> > > > The coupling of HDA in drm_audio_component framework makes the
> > > > register/unregister logic looks complicated to me as I don't use HDA
> > > > in my use case.
> > > > After some time, I found another patch series which also use component
> > > > framework to communicate between drm and mei world.
> > > >
> > > > https://patchwork.kernel.org/patch/10824527/
> > > >
> > > > And from that patch, I realized that I can follow the similar approach
> > > > to register a master component on ALSA side, a slave component on DRM
> > > > side, and use device and subcomponent to match them.
> > >
> > > Sorry for the confusion here. My suggestion is _not_ to use the component
> > > framework. That's only meant for one-off special case solutions. For that
> > > part I think you need to build a new register/unregister/bind/unbind
> > > infrastructure, like we have for lots of other things in the kernel
> > > already (clocks, gpio, drm_panel, drm_bridge as just a few examples).
> > >
> >
> > Hi Daniel,
> > Thank you for the prompt reply and guidance.
> >
> > I see. I was not aware that we should avoid using component framework.
> > Your example of drm_panel seems great.
> > I plan is to reuse drm_audio_components like this:
> > A LIST_HEAD holding the list of drm_audio_components instances, and add API
> > drm_audio_comp_init,
> > _add, _remove, _attach, _detach.
> > And for DRM side to look up the instance to use, we can use similar
> > approach like of_drm_find_panel, that is, using device tree node.
>
> Sounds good. I guess somewhere in there you'll use of_node/DT information
> to make sure you have the right audio component? Just to make sure we're
> agreeing on the design completely.
ACK.
I need to check closer. I will use of_node/DT information,
but it might be the other way around as machine driver can get the
hdmi node and hence hdmi device,
and that device can be passed to codec driver to register a component
with the device.
So the register mechanism is more like original hdmi_notifier.
>
>
> > > My suggestion with the i915/hda interface is to build on the actual
> > > interface for signalling connector status and exchanging eld and stuff
> > > like that.
> > >
> >
> > I agree with using this interface. But in my use case there is no much
> > data to be exchanged.
> > Only the connector status needs to be passed from DRM to ALSA world.
> > If in the future there is need for ALSA to make some call, that ops
> > can be added to drm_audio_component_ops.
>
> Yeah I think it's ok to not implement everyhing. Iirc we started with only
> the connector status too, then extended that to sharing the eld.
>
> There's also some i915/had hacks (clocks without using clock framework,
> power domains without using power framework), where for DT platforms we
> probably want to do this right.
>
> Looking at the entire thing we might need to create new _ops structures,
> or at least refactor them quite a bit. But we can improve things
> iteratively imo.
ACK
>
>
> > > > I should be able to do this without touching anything specific to HDA.
> > > > After that, DRM world should be able to use the ops in
> > > > drm_audio_component_audio_ops to notify ALSA world some event when
> > > > there is something happen in DRM world.
> > > > Currently the ops like pin_eld_notify, pin2port are too specific to HDA.
> > > > I think I can add an ops to drm_audio_component_audio_ops to convey
> > > > connector status.
> > >
> > > Hm why? The pin2port is maybe not the best one, since port is an intel
> > > construct, and pin a hda construct. So we'd need to change those to talk
> > > in terms of the higher-level concepts (alsa output pin and drm crtc
> > > probably).
> > >
> >
> > I took more look into how information of audio being present or not is
> > passed between DRM and ALSA world,
> > taking drivers/gpu/drm/i915/intel_audio.c and
> > sound/soc/codecs/hdac_hdmi.c as example.
> > I see the sequence is DRM side to call pin_eld_notify ops with port
> > and pipe to ALSA side.
> > Then, ALSA side calls get_eld ops with port and pipe to look up
> > whether the saved encoder has audio_connector.
> >
> > However, my use case on RK3288 is different in that ALSA side does not
> > need to get ELD.
> > I think adding an ops like connector_status() for DRM side to call in
> > parallel to pin_eld_notify is reasonable.
> > Both DRM side and ALSA side can choose what is the desired ops to be
> > implemented as these ops can be optional.
>
> I think pin_eld_notify and get_eld are just mislabeled, they give you both
> eld and status (the bool *enabled in get_eld). Maybe we should rename them
> to get_status and pin_status_notify?
ACK
>
> > > The other stuff should work a bit better. Either way my idea was to evolve
> > > that interface (and put in the place the required type-casting for
> > > i915/hda), since more users increases the odds that it actually is a good
> > > design.
> > >
> > Sorry I don't understand this part.
> > Could you please elaborate more about type-casting for i915/hda ?
> >
> > TBH, If possible, I would like to minimize the change I'll need to
> > make to i915/hda because of my limited knowledge of i915/hda and my
> > limited bandwidth.
> >
> > I would like to point out the scope of this problem to help the discussion.
> > I think this is a common need on boards using ALSA hdmi-codec driver.
> > Currently, there are many DRM drivers resorted to hdmi_codec_ops
> > approach to let ALSA world talks to DRM world.
> > That hdmi_codec_ops approach came around 2016 so it was before
> > drm_audio_component was introduced.
> > As for how jack status is reported for these boards, I am not sure,
> > maybe with local patches of hdmi-notifier.
> > So this is not a one-off change for RK3288 only. I believe other
> > boards will benefit from this jack reporting feature as well.
> >
> > As for extending and improving the interface of drm_audio_component so
> > more users can adopt it,
> > I think the ops in hdmi_codec_ops are good candidates to be moved to
> > drm_audio_component to consolidate the interface between DRM and ALSA
> > better.
> > That said, I don't feel a strong need to change i915/hda if the
> > purpose is to let more users use drm_audio_component.
> >
> > I can drew these changes in three stages:
> > 1. Add the infrastructure to add/remove/attach/detach
> > drm_audio_component (like how drm_panel does), and add
> > connector_status ops.
> > 2. Move ops in hdmi_codec_ops into drm_audio_components.
> > 3. Desired change of i915/hda (I am not clear about this part)
> >
> > I can help with 1 and 2 as Chromium tree have at least RK3288 and
> > MT8173 SoC using hdmi-codec driver so it is easier for me to try
> > patches.
> > And there may be more in the future.
> >
> > Thanks again for the patience.
> > I am not familiar with DRM so it takes me more time to digest your
> > comment and reply.
>
> Hm sorry, I totally forgot about this again, iirc I looked at this.
>
> Yeah fully agreeing that hdmi_audio_code is probably a better starting
> point. Problem is that becuase hdmi_codec is built on top of platform
> device it's quite a bit harder to extend with callbacks and things like
> that, without breaking the driver model.
>
> I need to think about this more, but if all we need to look at is
> hdmi_codec, then I think this becomes a lot easier. And we can ignore
> drm_audio_component.h completely.
It is surprising that you think this way.
Maybe the original patch before hdmi-notifier was introduced is the
better way to solve this issue, if we only need to look at hdmi_codec.
The history of hdmi_codec driver is in this patch series:
https://lore.kernel.org/patchwork/patch/539656/
There was a callback mechanism implemented between dw-hdmi and hdmi
codec driver.
It was later consolidated by Doug in this patch for better jack status
reporting:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/303573/
I am not sure why the original patch series did not get fully accepted
in the upstream.
It was quite long time ago.
But if you think this might be the right way to do, then it is even
better for us because the patch series and Doug's patch had been quite
stable
on our RK3288 products for about four years with plenty of users, so
we have much higher confidence in them.
I can rebase and clean up them and post another patch for review.
Please let me know what approach you feel is better.
Thanks again!
>
> -Daniel
>
>
> >
> > > > I will work toward this approach these days.
> > > > If you have other thought please let me know.
> > > > Thanks!
> > > >
> > > > > > I just need to report the connector status from synopsys/dw-hdmi.c to
> > > > > > codecs/hdmi-codec.c for codec driver to update the jack status.
> > > > > > Do you think I can proceed in this direction ? Or do you prefer I wait
> > > > > > for a while and work on it based on your new patch.
> > > > >
> > > > > I think most important part here is that we sync across all the different
> > > > > people pushing for better drm/alsa integration. What the solution looks
> > > > > like in the end doesn't matter much imo, as long as we don't end up with 3
> > > > > different things :-)
> > > >
> > > > Totally agree.
> > >
> > > Anyway just my thoughts, let's keep chatting.
> > >
> > > Cheers, Daniel
> > >
> > > > Thanks again!
> > > >
> > > > >
> > > > > Cheers, Daniel
> > > > >
> > > > > >
> > > > > > Thanks a lot!
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks again!
> > > > > > > >
> > > > > > > > > -Daniel
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Hans
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Modified by Cheng-Yi Chiang:
> > > > > > > > > > > - Add a section in MAINTAINER.
> > > > > > > > > > > - Changes connected and has_eld to bitfield of unsigned int.
> > > > > > > > > > > - Other minor fixes to pass checkpatch.pl --strict checks.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> > > > > > > > > > > Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
> > > > > > > > > > > ---
> > > > > > > > > > > The original patch is at
> > > > > > > > > > > https://lore.kernel.org/linux-arm-kernel/20161213150813.37966-2-hverkuil@xs4all.nl
> > > > > > > > > > >
> > > > > > > > > > > MAINTAINERS | 6 ++
> > > > > > > > > > > drivers/video/Kconfig | 3 +
> > > > > > > > > > > drivers/video/Makefile | 1 +
> > > > > > > > > > > drivers/video/hdmi-notifier.c | 145 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > include/linux/hdmi-notifier.h | 112 ++++++++++++++++++++++++++
> > > > > > > > > > > 5 files changed, 267 insertions(+)
> > > > > > > > > > > create mode 100644 drivers/video/hdmi-notifier.c
> > > > > > > > > > > create mode 100644 include/linux/hdmi-notifier.h
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > > > > > > > index 5cfbea4ce575..ffb7376f9509 100644
> > > > > > > > > > > --- a/MAINTAINERS
> > > > > > > > > > > +++ b/MAINTAINERS
> > > > > > > > > > > @@ -16676,6 +16676,12 @@ W: https://linuxtv.org
> > > > > > > > > > > S: Maintained
> > > > > > > > > > > F: drivers/media/platform/vicodec/*
> > > > > > > > > > >
> > > > > > > > > > > +VIDEO FRAMEWORK
> > > > > > > > > > > +M: Hans Verkuil <hverkuil@xs4all.nl>
> > > > > > > > > > > +L: linux-media@vger.kernel.org
> > > > > > > > > > > +F: drivers/video/hdmi-notifier.*
> > > > > > > > > > > +S: Maintained
> > > > > > > > > > > +
> > > > > > > > > > > VIDEO MULTIPLEXER DRIVER
> > > > > > > > > > > M: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > > > > > > > L: linux-media@vger.kernel.org
> > > > > > > > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > > > > > > > > index 83d3d271ca15..000ba9bc0ae7 100644
> > > > > > > > > > > --- a/drivers/video/Kconfig
> > > > > > > > > > > +++ b/drivers/video/Kconfig
> > > > > > > > > > > @@ -34,6 +34,9 @@ config VIDEOMODE_HELPERS
> > > > > > > > > > > config HDMI
> > > > > > > > > > > bool
> > > > > > > > > > >
> > > > > > > > > > > +config HDMI_NOTIFIERS
> > > > > > > > > > > + bool
> > > > > > > > > > > +
> > > > > > > > > > > endif # HAS_IOMEM
> > > > > > > > > > >
> > > > > > > > > > > if VT
> > > > > > > > > > > diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> > > > > > > > > > > index df7650adede9..eff4736102ca 100644
> > > > > > > > > > > --- a/drivers/video/Makefile
> > > > > > > > > > > +++ b/drivers/video/Makefile
> > > > > > > > > > > @@ -1,6 +1,7 @@
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > obj-$(CONFIG_VGASTATE) += vgastate.o
> > > > > > > > > > > obj-$(CONFIG_HDMI) += hdmi.o
> > > > > > > > > > > +obj-$(CONFIG_HDMI_NOTIFIERS) += hdmi-notifier.o
> > > > > > > > > > >
> > > > > > > > > > > obj-$(CONFIG_VT) += console/
> > > > > > > > > > > obj-$(CONFIG_FB_STI) += console/
> > > > > > > > > > > diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..d1eedf661648
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/drivers/video/hdmi-notifier.c
> > > > > > > > > > > @@ -0,0 +1,145 @@
> > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > +/* hdmi-notifier.c - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/export.h>
> > > > > > > > > > > +#include <linux/hdmi-notifier.h>
> > > > > > > > > > > +#include <linux/string.h>
> > > > > > > > > > > +#include <linux/slab.h>
> > > > > > > > > > > +#include <linux/list.h>
> > > > > > > > > > > +
> > > > > > > > > > > +static LIST_HEAD(hdmi_notifiers);
> > > > > > > > > > > +static DEFINE_MUTEX(hdmi_notifiers_lock);
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n;
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_for_each_entry(n, &hdmi_notifiers, head) {
> > > > > > > > > > > + if (n->dev == dev) {
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + return n;
> > > > > > > > > > > + }
> > > > > > > > > > > + }
> > > > > > > > > > > + n = kzalloc(sizeof(*n), GFP_KERNEL);
> > > > > > > > > > > + if (!n)
> > > > > > > > > > > + goto unlock;
> > > > > > > > > > > + n->dev = dev;
> > > > > > > > > > > + mutex_init(&n->lock);
> > > > > > > > > > > + BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
> > > > > > > > > > > + kref_init(&n->kref);
> > > > > > > > > > > + list_add_tail(&n->head, &hdmi_notifiers);
> > > > > > > > > > > +unlock:
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + return n;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_get);
> > > > > > > > > > > +
> > > > > > > > > > > +static void hdmi_notifier_release(struct kref *kref)
> > > > > > > > > > > +{
> > > > > > > > > > > + struct hdmi_notifier *n =
> > > > > > > > > > > + container_of(kref, struct hdmi_notifier, kref);
> > > > > > > > > > > +
> > > > > > > > > > > + mutex_lock(&hdmi_notifiers_lock);
> > > > > > > > > > > + list_del(&n->head);
> > > > > > > > > > > + mutex_unlock(&hdmi_notifiers_lock);
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + kfree(n);
> > > > > > > > > > > +}
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + kref_put(&n->kref, hdmi_notifier_release);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_put);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_register(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret)
> > > > > > > > > > > + return ret;
> > > > > > > > > > > + kref_get(&n->kref);
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->connected) {
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + if (n->edid_size)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_EDID, n);
> > > > > > > > > > > + if (n->has_eld)
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers,
> > > > > > > > > > > + HDMI_NEW_ELD, n);
> > > > > > > > > > > + }
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_register);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block *nb)
> > > > > > > > > > > +{
> > > > > > > > > > > + int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
> > > > > > > > > > > +
> > > > > > > > > > > + if (ret == 0)
> > > > > > > > > > > + hdmi_notifier_put(n);
> > > > > > > > > > > + return ret;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_CONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_connect);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + n->connected = false;
> > > > > > > > > > > + n->has_eld = false;
> > > > > > > > > > > + n->edid_size = 0;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_DISCONNECTED, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
> > > > > > > > > > > +
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + if (n->edid_allocated_size < size) {
> > > > > > > > > > > + void *p = kmalloc(size, GFP_KERNEL);
> > > > > > > > > > > +
> > > > > > > > > > > + if (!p) {
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return -ENOMEM;
> > > > > > > > > > > + }
> > > > > > > > > > > + kfree(n->edid);
> > > > > > > > > > > + n->edid = p;
> > > > > > > > > > > + n->edid_allocated_size = size;
> > > > > > > > > > > + }
> > > > > > > > > > > + memcpy(n->edid, edid, size);
> > > > > > > > > > > + n->edid_size = size;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_EDID, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > + return 0;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_edid);
> > > > > > > > > > > +
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128])
> > > > > > > > > > > +{
> > > > > > > > > > > + mutex_lock(&n->lock);
> > > > > > > > > > > + memcpy(n->eld, eld, sizeof(n->eld));
> > > > > > > > > > > + n->has_eld = true;
> > > > > > > > > > > + blocking_notifier_call_chain(&n->notifiers, HDMI_NEW_ELD, n);
> > > > > > > > > > > + mutex_unlock(&n->lock);
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL_GPL(hdmi_event_new_eld);
> > > > > > > > > > > diff --git a/include/linux/hdmi-notifier.h b/include/linux/hdmi-notifier.h
> > > > > > > > > > > new file mode 100644
> > > > > > > > > > > index 000000000000..c8f35110e3e3
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/include/linux/hdmi-notifier.h
> > > > > > > > > > > @@ -0,0 +1,112 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > + * hdmi-notifier.h - notify interested parties of (dis)connect and EDID
> > > > > > > > > > > + * events
> > > > > > > > > > > + *
> > > > > > > > > > > + * Copyright 2016 Russell King <rmk+kernel@arm.linux.org.uk>
> > > > > > > > > > > + * Copyright 2016 Cisco Systems, Inc. and/or its affiliates.
> > > > > > > > > > > + * All rights reserved.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +#define LINUX_HDMI_NOTIFIER_H
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/types.h>
> > > > > > > > > > > +#include <linux/notifier.h>
> > > > > > > > > > > +#include <linux/kref.h>
> > > > > > > > > > > +
> > > > > > > > > > > +enum {
> > > > > > > > > > > + HDMI_CONNECTED,
> > > > > > > > > > > + HDMI_DISCONNECTED,
> > > > > > > > > > > + HDMI_NEW_EDID,
> > > > > > > > > > > + HDMI_NEW_ELD,
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +struct device;
> > > > > > > > > > > +
> > > > > > > > > > > +struct hdmi_notifier {
> > > > > > > > > > > + /* Lock to protect callback registration and notification. */
> > > > > > > > > > > + struct mutex lock;
> > > > > > > > > > > + struct list_head head;
> > > > > > > > > > > + struct kref kref;
> > > > > > > > > > > + struct blocking_notifier_head notifiers;
> > > > > > > > > > > + struct device *dev;
> > > > > > > > > > > +
> > > > > > > > > > > + /* Current state */
> > > > > > > > > > > + unsigned int connected : 1;
> > > > > > > > > > > + unsigned int has_eld : 1;
> > > > > > > > > > > + unsigned char eld[128];
> > > > > > > > > > > + void *edid;
> > > > > > > > > > > + size_t edid_size;
> > > > > > > > > > > + size_t edid_allocated_size;
> > > > > > > > > > > +};
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_get - find or create a new hdmi_notifier for the given device.
> > > > > > > > > > > + * @dev: device that sends the events.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If a notifier for device @dev already exists, then increase the refcount
> > > > > > > > > > > + * and return that notifier.
> > > > > > > > > > > + *
> > > > > > > > > > > + * If it doesn't exist, then allocate a new notifier struct and return a
> > > > > > > > > > > + * pointer to that new struct.
> > > > > > > > > > > + *
> > > > > > > > > > > + * Return NULL if the memory could not be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +struct hdmi_notifier *hdmi_notifier_get(struct device *dev);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_put - decrease refcount and delete when the refcount reaches 0.
> > > > > > > > > > > + * @n: notifier
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_notifier_put(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_register - register the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_notifier_unregister - unregister the notifier with the notifier_block.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + * @nb: the notifier_block
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_notifier_unregister(struct hdmi_notifier *n,
> > > > > > > > > > > + struct notifier_block *nb);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_connect - send a connect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_CONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_connect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_disconnect - send a disconnect event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_DISCONNECTED event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_disconnect(struct hdmi_notifier *n);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_edid - send a new EDID event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_EDID event to any registered parties.
> > > > > > > > > > > + * This function will make a copy the EDID so it can return -ENOMEM if
> > > > > > > > > > > + * no memory could be allocated.
> > > > > > > > > > > + */
> > > > > > > > > > > +int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size);
> > > > > > > > > > > +
> > > > > > > > > > > +/**
> > > > > > > > > > > + * hdmi_event_new_eld - send a new ELD event.
> > > > > > > > > > > + * @n: the HDMI notifier
> > > > > > > > > > > + *
> > > > > > > > > > > + * Send an HDMI_NEW_ELD event to any registered parties.
> > > > > > > > > > > + */
> > > > > > > > > > > +void hdmi_event_new_eld(struct hdmi_notifier *n, const u8 eld[128]);
> > > > > > > > > > > +
> > > > > > > > > > > +#endif
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Daniel Vetter
> > > > > > > > > Software Engineer, Intel Corporation
> > > > > > > > > http://blog.ffwll.ch
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Vetter
> > > > > > > Software Engineer, Intel Corporation
> > > > > > > http://blog.ffwll.ch
> > > > >
> > > > > --
> > > > > Daniel Vetter
> > > > > Software Engineer, Intel Corporation
> > > > > http://blog.ffwll.ch
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v5 06/11] ima-evm-utils: Start converting find_keyid to use EVP_PKEY API
From: Mimi Zohar @ 2019-06-20 13:21 UTC (permalink / raw)
To: Vitaly Chikunov; +Cc: Mimi Zohar, Dmitry Kasatkin, linux-integrity
In-Reply-To: <20190620010713.wfmkjkf3fprgc3h6@altlinux.org>
Hi Vitaly,
> > > > If so, why are there other changes in this patch?
> > >
> > > There is no other changes beside stated in description.
> >
> > Are the changes from read_pub_key() to read_pub_pkey() and
> > calc_keyid_v2() to calc_pkeyid_v2() needed for making find_keyid() a
> > wrapper for find_keyid_pkey()?
>
> Of course. `entry->key' now have different type. If we keep old type
> (RSA) where will be nothing to wrap.
The question wasn't if the changes in init_public_keys() need to be
made, the question is its correlation to find_keyid(). Unlesss I'm
missing something, find_keyid() is only called by verify_hash_v2(),
not calc_keyid_v2().
Mimi
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] memory: do not do out of bound notification
From: Peter Xu @ 2019-06-20 12:59 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Auger Eric, Yan Zhao, qemu-devel
In-Reply-To: <6829b139-3eab-449e-04d6-07f1e381316d@redhat.com>
On Thu, Jun 20, 2019 at 10:35:29AM +0200, Paolo Bonzini wrote:
> On 20/06/19 06:02, Peter Xu wrote:
> > Seems workable, to be explicit - we can even cut it into chunks with
> > different size to be efficient.
>
> Yes, this is not hard (completely untested):
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 44b1231157..541538bc6c 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -3388,39 +3388,34 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
> }
>
> assert(start <= end);
> - size = end - start;
> + while (end > start) {
> + size = end - start;
> + /* Only keep the lowest bit of either size or start. */
> + size = MIN(size & -size, start & -start);
I feel like this can be problematic. I'm imaging:
start=0x1000_0000, size=0x1000_1000
This will get size=0x1000 but actually we can do size=0x1000_0000 as
the first.
> + /* Should not happen, but limit to address width too just in case */
> + size = MIN(size, 1ULL << s->aw_bits);
>
> - if (ctpop64(size) != 1) {
> - /*
> - * This size cannot format a correct mask. Let's enlarge it to
> - * suite the minimum available mask.
> - */
> - int n = 64 - clz64(size);
> - if (n > s->aw_bits) {
> - /* should not happen, but in case it happens, limit it */
> - n = s->aw_bits;
> - }
> - size = 1ULL << n;
> - }
> + assert((start & (size - 1)) == 0);
>
> - entry.target_as = &address_space_memory;
> - /* Adjust iova for the size */
> - entry.iova = n->start & ~(size - 1);
> - /* This field is meaningless for unmap */
> - entry.translated_addr = 0;
> - entry.perm = IOMMU_NONE;
> - entry.addr_mask = size - 1;
> + entry.target_as = &address_space_memory;
> + entry.iova = start;
> + /* This field is meaningless for unmap */
> + entry.translated_addr = 0;
> + entry.perm = IOMMU_NONE;
> + entry.addr_mask = size - 1;
(some of the fields can be moved out of loop because they are
constants)
>
> - trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
> - VTD_PCI_SLOT(as->devfn),
> - VTD_PCI_FUNC(as->devfn),
> - entry.iova, size);
> + trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
> + VTD_PCI_SLOT(as->devfn),
> + VTD_PCI_FUNC(as->devfn),
> + entry.iova, size);
Can move this out because this is a trace only so we don't have
restriction on mask?
>
> - map.iova = entry.iova;
> - map.size = entry.addr_mask;
> - iova_tree_remove(as->iova_tree, &map);
> + map.iova = entry.iova;
> + map.size = entry.addr_mask;
> + iova_tree_remove(as->iova_tree, &map);
Same here?
>
> - memory_region_notify_one(n, &entry);
> + memory_region_notify_one(n, &entry);
> + start += size;
> + }
> }
>
> static void vtd_address_space_unmap_all(IntelIOMMUState *s)
>
>
> Yan,
>
> if something like this works for you, let me know and I will submit it
> as a proper patch.
>
> Paolo
Since during review I'm thinking how to generate a correct sequence of
these masks... here's my try below with above issues fixed... :)
I've tried compile but not tested. Yan can test it, or I can do it
too tomorrow after I find some machines.
Thanks,
------------------------------------------------------------
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 44b1231157..cfbd225f0a 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -3363,11 +3363,32 @@ VTDAddressSpace *vtd_find_add_as(IntelIOMMUState *s, PCIBus *bus, int devfn)
return vtd_dev_as;
}
+static uint64_t vtd_get_next_mask(uint64_t start, uint64_t size, int gaw)
+{
+ /* Tries to find smallest mask from start first */
+ uint64_t rmask = start & -start, max_mask = 1ULL << gaw;
+
+ assert(size && gaw > 0 && gaw < 64);
+
+ /* Zero start, or too big */
+ if (!rmask || rmask > max_mask) {
+ rmask = max_mask;
+ }
+
+ /* If the start mask worked, then use it */
+ if (rmask <= size) {
+ return rmask;
+ }
+
+ /* Find the largest page mask from size */
+ return 1ULL << (63 - clz64(size));
+}
+
/* Unmap the whole range in the notifier's scope. */
static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
{
IOMMUTLBEntry entry;
- hwaddr size;
+ hwaddr size, remain;
hwaddr start = n->start;
hwaddr end = n->end;
IntelIOMMUState *s = as->iommu_state;
@@ -3388,39 +3409,28 @@ static void vtd_address_space_unmap(VTDAddressSpace *as, IOMMUNotifier *n)
}
assert(start <= end);
- size = end - start;
-
- if (ctpop64(size) != 1) {
- /*
- * This size cannot format a correct mask. Let's enlarge it to
- * suite the minimum available mask.
- */
- int n = 64 - clz64(size);
- if (n > s->aw_bits) {
- /* should not happen, but in case it happens, limit it */
- n = s->aw_bits;
- }
- size = 1ULL << n;
- }
-
+ size = remain = end - start;
entry.target_as = &address_space_memory;
- /* Adjust iova for the size */
- entry.iova = n->start & ~(size - 1);
+ entry.perm = IOMMU_NONE;
/* This field is meaningless for unmap */
entry.translated_addr = 0;
- entry.perm = IOMMU_NONE;
- entry.addr_mask = size - 1;
+
+ while (remain) {
+ uint64_t mask = vtd_get_next_mask(start, remain, s->aw_bits);
+
+ entry.iova = start;
+ entry.addr_mask = mask - 1;
+ memory_region_notify_one(n, &entry);
+ }
trace_vtd_as_unmap_whole(pci_bus_num(as->bus),
VTD_PCI_SLOT(as->devfn),
VTD_PCI_FUNC(as->devfn),
- entry.iova, size);
+ n->start, size);
- map.iova = entry.iova;
- map.size = entry.addr_mask;
+ map.iova = n->start;
+ map.size = size;
iova_tree_remove(as->iova_tree, &map);
-
- memory_region_notify_one(n, &entry);
}
static void vtd_address_space_unmap_all(IntelIOMMUState *s)
------------------------------------------------------------
Regards,
--
Peter Xu
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.