History log of /openbmc/linux/drivers/media/platform/amphion/vpu_core.c (Results 1 – 13 of 13)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1
# c082791b 07-Nov-2023 Alexander Stein <alexander.stein@ew.tq-group.com>

media: amphion: Fix VPU core alias name

[ Upstream commit f033c87fda47e272bb4f75dc7b03677261d91158 ]

Starting with commit f6038de293f2 ("arm64: dts: imx8qm: Fix VPU core
alias name") the alias for

media: amphion: Fix VPU core alias name

[ Upstream commit f033c87fda47e272bb4f75dc7b03677261d91158 ]

Starting with commit f6038de293f2 ("arm64: dts: imx8qm: Fix VPU core
alias name") the alias for VPU cores uses dashes instead of underscores.
Adjust the alias stem accordingly. Fixes the errors:
amphion-vpu-core 2d040000.vpu-core: can't get vpu core id
amphion-vpu-core 2d050000.vpu-core: can't get vpu core id

Fixes: f6038de293f2 ("arm64: dts: imx8qm: Fix VPU core alias name")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...


Revision tags: v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39
# 5bd28eae 18-Jul-2023 Ming Qian <ming.qian@nxp.com>

media: amphion: ensure the bitops don't cross boundaries

the supported_instance_count determine the instance index range,
it shouldn't exceed the bits number of instance_mask,
otherwise the bitops o

media: amphion: ensure the bitops don't cross boundaries

the supported_instance_count determine the instance index range,
it shouldn't exceed the bits number of instance_mask,
otherwise the bitops of instance_mask may cross boundaries

Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


# 7c7e33b7 14-Jul-2023 Rob Herring <robh@kernel.org>

media: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that m

media: Explicitly include correct DT includes

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.

Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31
# dcff0b56 25-May-2023 Nicolas Dufresne <nicolas.dufresne@collabora.com>

media: amphion: Fix firmware path to match linux-firmware

The path did not match the one it was submitted into linux-firmware
which prevented generic distribution from having working CODEC.

Fixes:

media: amphion: Fix firmware path to match linux-firmware

The path did not match the one it was submitted into linux-firmware
which prevented generic distribution from having working CODEC.

Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


Revision tags: v6.1.30
# bce487a4 23-May-2023 Tejun Heo <tj@kernel.org>

media: amphion: Use alloc_ordered_workqueue() to create ordered workqueues

BACKGROUND
==========

When multiple work items are queued to a workqueue, their execution order
doesn't match the queueing

media: amphion: Use alloc_ordered_workqueue() to create ordered workqueues

BACKGROUND
==========

When multiple work items are queued to a workqueue, their execution order
doesn't match the queueing order. They may get executed in any order and
simultaneously. When fully serialized execution - one by one in the
queueing order - is needed, an ordered workqueue should be used which can
be created with alloc_ordered_workqueue().

However, alloc_ordered_workqueue() was a later addition. Before it, an
ordered workqueue could be obtained by creating an UNBOUND workqueue with
@max_active==1. This originally was an implementation side-effect which was
broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
ordered"). Because there were users that depended on the ordered execution,
5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be ordered")
made workqueue allocation path to implicitly promote UNBOUND workqueues w/
@max_active==1 to ordered workqueues.

While this has worked okay, overloading the UNBOUND allocation interface
this way creates other issues. It's difficult to tell whether a given
workqueue actually needs to be ordered and users that legitimately want a
min concurrency level wq unexpectedly gets an ordered one instead. With
planned UNBOUND workqueue updates to improve execution locality and more
prevalence of chiplet designs which can benefit from such improvements,
this isn't a state we wanna be in forever.

This patch series audits all callsites that create an UNBOUND workqueue w/
@max_active==1 and converts them to alloc_ordered_workqueue() as necessary.

WHAT TO LOOK FOR
================

The conversions are from

alloc_workqueue(WQ_UNBOUND | flags, 1, args..)

to

alloc_ordered_workqueue(flags, args...)

which don't cause any functional changes. If you know that fully ordered
execution is not necessary, please let me know. I'll drop the conversion
and instead add a comment noting the fact to reduce confusion while
conversion is in progress.

If you aren't fully sure, it's completely fine to let the conversion
through. The behavior will stay exactly the same and we can always
reconsider later.

As there are follow-up workqueue core changes, I'd really appreciate if the
patch can be routed through the workqueue tree w/ your acks. Thanks.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Ming Qian <ming.qian@nxp.com>
Cc: Shijie Qin <shijie.qin@nxp.com>
Cc: Zhou Peng <eagle.zhou@nxp.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-media@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>

show more ...


Revision tags: v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22
# a3b4ab60 26-Mar-2023 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

media: vpu_core: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do err

media: vpu_core: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...


Revision tags: v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62
# 0202a665 17-Aug-2022 Ming Qian <ming.qian@nxp.com>

media: amphion: fix a bug that vpu core may not resume after suspend

driver will enable the vpu core when request the first instance
on the core.
one vpu core can only support 8 streaming instances

media: amphion: fix a bug that vpu core may not resume after suspend

driver will enable the vpu core when request the first instance
on the core.
one vpu core can only support 8 streaming instances in the same
time, the instance won't be added to core's list before streamon.

so the actual instance count may be greater then the number in
the core's list.

in pm resume callback, driver will resume the core immediately if
core's list is not empty.
but this check is not accurate,
if suspend during one instance is requested, but not streamon,
then after suspend, the core won't be resume, and led to instance failure.

use the request_count instead of the core's list to check
whether is the core needed to resume immediately after suspend.

And it can make the pm suspend and resume callback more clear.

Fixes: 9f599f351e86 ("media: amphion: add vpu core driver")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


Revision tags: v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51
# a621cc4b 28-Jun-2022 Ming Qian <ming.qian@nxp.com>

media: amphion: release core lock before reset vpu core

In reset vpu core, driver will wait for a response event,
but if there are still some events unhandled,
they will be handled first, driver may

media: amphion: release core lock before reset vpu core

In reset vpu core, driver will wait for a response event,
but if there are still some events unhandled,
they will be handled first, driver may acquire core lock for that.
So if we do reset in core lock, it may led to reset timeout.

Fixes: 9f599f351e86a ("media: amphion: add vpu core driver")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


Revision tags: v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41
# 9059ca92 17-May-2022 Ming Qian <ming.qian@nxp.com>

media: amphion: support for reloading module

As there is no interface to power off vpu core.
So it need to boot from cold on first load.
but on the second load, driver need to restore the status
ins

media: amphion: support for reloading module

As there is no interface to power off vpu core.
So it need to boot from cold on first load.
but on the second load, driver need to restore the status
instead of booting.

Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


Revision tags: v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28
# a9f7224c 10-Mar-2022 Ming Qian <ming.qian@nxp.com>

media: amphion: fix some issues to improve robust

fix some issues reported by Dan,
1. fix some signedness bug
2. don't use u32 as function return value
3. prevent a divide by zero bug
4. Just return

media: amphion: fix some issues to improve robust

fix some issues reported by Dan,
1. fix some signedness bug
2. don't use u32 as function return value
3. prevent a divide by zero bug
4. Just return zero on success, don't return a known parameter
5. check the validity of some variables
6. reset buffer state when return buffers
7. make sure the ALIGN won't wrap to zero

Signed-off-by: Ming Qian <ming.qian@nxp.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


# f445014a 10-Mar-2022 Ming Qian <ming.qian@nxp.com>

media: amphion: fix an issue that using pm_runtime_get_sync incorrectly

pm_runtime_get_sync() also returns 1 on success.
The documentation for pm_runtime_get_sync() suggests using
pm_runtime_resume_

media: amphion: fix an issue that using pm_runtime_get_sync incorrectly

pm_runtime_get_sync() also returns 1 on success.
The documentation for pm_runtime_get_sync() suggests using
pm_runtime_resume_and_get() instead

Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


# 5d1ca138 16-Mar-2022 Xiongfeng Wang <wangxiongfeng2@huawei.com>

media: amphion: Add missing of_node_put() in vpu_core_parse_dt()

of_parse_phandle() will increment the refcount of the returned
device_node. Calling of_node_put() to avoid the refcount leak.

Link:

media: amphion: Add missing of_node_put() in vpu_core_parse_dt()

of_parse_phandle() will increment the refcount of the returned
device_node. Calling of_node_put() to avoid the refcount leak.

Link: https://lore.kernel.org/linux-media/20220316081938.80819-1-wangxiongfeng2@huawei.com
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>

show more ...


Revision tags: v5.15.27, v5.15.26
# 9f599f35 23-Feb-2022 Ming Qian <ming.qian@nxp.com>

media: amphion: add vpu core driver

The vpu supports encoder and decoder.
it needs vpu core to handle it.
core will run either encoder or decoder firmware.

This driver is for support the vpu core.

media: amphion: add vpu core driver

The vpu supports encoder and decoder.
it needs vpu core to handle it.
core will run either encoder or decoder firmware.

This driver is for support the vpu core.

Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Shijie Qin <shijie.qin@nxp.com>
Signed-off-by: Zhou Peng <eagle.zhou@nxp.com>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>

show more ...