Should CONFIG_VIDEOBUF2_CORE / CONFIG_VIDEOBUF2_MEMOPS be a module? |
||||
Issue descriptionAs discussed on crosreview.com/887920, in kernel 4.14 it appears that we're not terribly consistent about whether these should be modules or builtin: $ git grep CONFIG_VIDEOBUF2_ -- chromeos chromeos/config/arm64/chromiumos-arm64.flavour.config:CONFIG_VIDEOBUF2_CORE=y chromeos/config/arm64/chromiumos-arm64.flavour.config:CONFIG_VIDEOBUF2_DMA_CONTIG=y chromeos/config/arm64/chromiumos-arm64.flavour.config:CONFIG_VIDEOBUF2_MEMOPS=y chromeos/config/arm64/chromiumos-mediatek.flavour.config:CONFIG_VIDEOBUF2_CORE=y chromeos/config/arm64/chromiumos-mediatek.flavour.config:CONFIG_VIDEOBUF2_DMA_CONTIG=y chromeos/config/arm64/chromiumos-mediatek.flavour.config:CONFIG_VIDEOBUF2_MEMOPS=y chromeos/config/arm64/chromiumos-rockchip64.flavour.config:CONFIG_VIDEOBUF2_CORE=m chromeos/config/arm64/chromiumos-rockchip64.flavour.config:CONFIG_VIDEOBUF2_MEMOPS=m chromeos/config/armel/common.config:CONFIG_VIDEOBUF2_CORE=m chromeos/config/armel/common.config:CONFIG_VIDEOBUF2_MEMOPS=m chromeos/config/base.config:CONFIG_VIDEOBUF2_VMALLOC=m chromeos/config/i386/common.config:CONFIG_VIDEOBUF2_CORE=m chromeos/config/i386/common.config:CONFIG_VIDEOBUF2_MEMOPS=m chromeos/config/x86_64/common.config:CONFIG_VIDEOBUF2_CORE=m chromeos/config/x86_64/common.config:CONFIG_VIDEOBUF2_MEMOPS=m --- Is there a good reason why some people have this builtin and others have it as a module?
,
Jan 29 2018
4.4, for reference: $ git grep CONFIG_VIDEOBUF2_ -- chromeos chromeos/config/arm64/chromiumos-arm64.flavour.config:CONFIG_VIDEOBUF2_VMALLOC=m chromeos/config/arm64/chromiumos-mediatek.flavour.config:CONFIG_VIDEOBUF2_VMALLOC=m chromeos/config/arm64/chromiumos-rockchip64.flavour.config:CONFIG_VIDEOBUF2_VMALLOC=y chromeos/config/arm64/common.config:CONFIG_VIDEOBUF2_CORE=y chromeos/config/arm64/common.config:CONFIG_VIDEOBUF2_DMA_CONTIG=y chromeos/config/arm64/common.config:CONFIG_VIDEOBUF2_MEMOPS=y chromeos/config/armel/common.config:CONFIG_VIDEOBUF2_CORE=m chromeos/config/armel/common.config:CONFIG_VIDEOBUF2_MEMOPS=m chromeos/config/armel/common.config:CONFIG_VIDEOBUF2_VMALLOC=m chromeos/config/i386/common.config:CONFIG_VIDEOBUF2_CORE=m chromeos/config/i386/common.config:CONFIG_VIDEOBUF2_MEMOPS=m chromeos/config/i386/common.config:CONFIG_VIDEOBUF2_VMALLOC=m chromeos/config/x86_64/chromeos-intel-pineview.flavour.config:CONFIG_VIDEOBUF2_DMA_SG=m chromeos/config/x86_64/common.config:CONFIG_VIDEOBUF2_CORE=m chromeos/config/x86_64/common.config:CONFIG_VIDEOBUF2_MEMOPS=m chromeos/config/x86_64/common.config:CONFIG_VIDEOBUF2_VMALLOC=m
,
Feb 1 2018
We should be ok with =m in general, however, to my memory, I believe we had to switch to =y to ensure relevant /dev nodes were created and udev triggers executed before UI was up for video capability autodetection on Chrome startup. This should probably be doable with proper organization in startup scripts with =m as well, but I would prefer not to switch from existing =y to =m before we are able to ensure/verify that.
,
Feb 1 2018
,
Feb 1 2018
,
Feb 1 2018
So does that mean that those platforms that have "=m" have a bug?
,
Feb 1 2018
Pawel is right. GPU process checks the video capability on Chrome startup early. We changed to =m to make sure video nodes are ready before GPU process checking it. Intel doesn't use V4L2 codec drivers. ARM all use V4L2 codec drivers. If an ARM platform does not use =m, it should be a bug.
,
Feb 1 2018
Sorry. There was a typo. If an ARM platform uses =m, it should be a bug.
,
Feb 1 2018
#7, I think you mean "We changed to =y to make sure video nodes are ready before GPU process checking it." (s/=m/=r/) right? Perhaps it wouldn't be a bad idea to actually retest this? The original initialization order issue might have been fixed.
,
Feb 1 2018
Okay, I just tested on Kevin and it doesn't work. Chrome doesn't detect the video nodes and falls back to software codecs. |
||||
►
Sign in to add a comment |
||||
Comment 1 Deleted