kernel/linux.git/drivers/media/platform/qcom, branch v6.2

Merge tag 'tag-venus-for-v6.2' of git://linuxtv.org/svarbanov/media_tree into media_stage

2022-11-15T11:53:57+00:00

Venus updates for v6.2 * tag 'tag-venus-for-v6.2' of git://linuxtv.org/svarbanov/media_tree: venus: pm_helpers: Fix error check in vcodec_domains_get() venus: firmware: Correct assertion of reset bit on remote processor venus: firmware: Correct non-pix start and end addresses venus: firmware: Correct reset bit MAINTAINERS: Change email for Venus driver MAINTAINERS: Add Vikash as VENUS video driver co-maintainer

media: camss: Split power domain management

2022-11-08T08:41:36+00:00

There are three cases of power domain management on supported platforms: 1) CAMSS on MSM8916, where a single VFE power domain is operated outside of the camss device driver, 2) CAMSS on MSM8996 and SDM630/SDM660, where two VFE power domains are managed separately by the camss device driver, the power domains are linked and unlinked on demand by their functions vfe_pm_domain_on() and vfe_pm_domain_off() respectively, 3) CAMSS on SDM845 and SM8250 platforms, and there are two VFE power domains and their parent power domain TITAN_TOP, the latter one shall be turned on prior to turning on any of VFE power domains. Due to a previously missing link between TITAN_TOP and VFEx power domains in the latter case, which is now fixed by [1], it was decided always to turn on all found VFE power domains and TITAN_TOP power domain, even if just one particular VFE is needed to be enabled or none of VFE power domains are required, for instance the latter case is when vfe_lite is in use. This misusage becomes more incovenient and clumsy, if next generations are to be supported, for instance CAMSS on SM8450 has three VFE power domains. The change splits the power management support for platforms with TITAN_TOP parent power domain, and, since 'power-domain-names' property is not present in camss device tree nodes, the assumption is that the first N power domains from the 'power-domains' list correspond to VFE power domains, and, if the number of power domains is greater than number of non-lite VFEs, then the last power domain from the list is the TITAN_TOP power domain. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Robert Foss Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: camss: Collect information about a number of lite VFEs

2022-11-08T08:40:20+00:00

VFE lite IPs are found on CAMSS with TITAN_TOP power domains, and in some aspects these types of VFEs are different, in particular there is no need to enable VFE power domains to operate over VFE lite IPs. Signed-off-by: Vladimir Zapolskiy Reviewed-by: Robert Foss Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: camss: Do not attach an already attached power domain on MSM8916 platform

2022-11-08T08:39:33+00:00

The change to dynamically allocated power domains neglected a case of CAMSS on MSM8916 platform, where a single VFE power domain is neither attached, linked or managed in runtime in any way explicitly. This is a special case and it shall be kept as is, because the power domain management is done outside of the driver, and it's very different in comparison to all other platforms supported by CAMSS. Fixes: 6b1814e26989 ("media: camss: Allocate power domain resources dynamically") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Robert Foss Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

media: camss: Clean up received buffers on failed start of streaming

2022-11-08T08:39:08+00:00

It is required to return the received buffers, if streaming can not be started. For instance media_pipeline_start() may fail with EPIPE, if a link validation between entities is not passed, and in such a case a user gets a kernel warning: WARNING: CPU: 1 PID: 520 at drivers/media/common/videobuf2/videobuf2-core.c:1592 vb2_start_streaming+0xec/0x160 Call trace: vb2_start_streaming+0xec/0x160 vb2_core_streamon+0x9c/0x1a0 vb2_ioctl_streamon+0x68/0xbc v4l_streamon+0x30/0x3c __video_do_ioctl+0x184/0x3e0 video_usercopy+0x37c/0x7b0 video_ioctl2+0x24/0x40 v4l2_ioctl+0x4c/0x70 The fix is to correct the error path in video_start_streaming() of camss. Fixes: 0ac2586c410f ("media: camss: Add files which handle the video device nodes") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Robert Foss Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab

venus: pm_helpers: Fix error check in vcodec_domains_get()

2022-10-25T07:38:56+00:00

In the function vcodec_domains_get(), dev_pm_domain_attach_by_name() may return NULL in some cases, so IS_ERR() doesn't meet the requirements. Thus fix it. Fixes: 7482a983dea3 ("media: venus: redesign clocks and pm domains control") Signed-off-by: Tang Bin

venus: firmware: Correct assertion of reset bit on remote processor

2022-10-25T07:32:02+00:00

Currently we use read/write_relaxed in combination with mb() to assert reset. This looks wrong because mb() after write_relaxed() will not order correctly load-update-store sequence. Correct this by use readl/writel which include memory barriers. Signed-off-by: Stanimir Varbanov

venus: firmware: Correct non-pix start and end addresses

2022-10-25T07:31:54+00:00

The default values for those registers are zero. Signed-off-by: Stanimir Varbanov

venus: firmware: Correct reset bit

2022-10-25T07:31:48+00:00

The reset bit for A9SS reset register is BIT(4) and for XTSS_SW_RESET it is BIT(0). Use the defines for those reset bits. Signed-off-by: Stanimir Varbanov

media: venus: hfi: Remove the unneeded result variable

2022-09-24T09:21:44+00:00

Return the value venus_hfi_create() directly instead of storing it in another redundant variable. Signed-off-by: ye xingchen Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab