| aa89281b | 12-Jun-2025 |
Jacopo Mondi <jacopo.mondi@ideasonboard.com> |
media: pisp_be: Use clamp() and define max sizes
Use the clamp() function from minmax.h and provide a define for the max
sizes as they will be used in subsequent patches.
Reviewed-by: Daniel Scally
media: pisp_be: Use clamp() and define max sizes
Use the clamp() function from minmax.h and provide a define for the max
sizes as they will be used in subsequent patches.
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
show more ...
|
| e9bb2eac | 26-Aug-2024 |
Jacopo Mondi <jacopo.mondi@ideasonboard.com> |
media: pisp_be: Fix pm_runtime underrun in probe
During the probe() routine, the PiSP BE driver needs to power up the
interface in order to identify and initialize the hardware.
The driver resumes
media: pisp_be: Fix pm_runtime underrun in probe
During the probe() routine, the PiSP BE driver needs to power up the
interface in order to identify and initialize the hardware.
The driver resumes the interface by calling the
pispbe_runtime_resume() function directly, without going
through the pm_runtime helpers, but later suspends it by calling
pm_runtime_put_autosuspend().
This causes a PM usage count imbalance at probe time, notified by the
runtime_pm framework with the below message in the system log:
pispbe 1000880000.pisp_be: Runtime PM usage count underflow!
Fix this by resuming the interface using the pm runtime helpers instead
of calling the resume function directly and use the pm_runtime framework
in the probe() error path. While at it, remove manual suspend of the
interface in the remove() function. The driver cannot be unloaded if in
use, so simply disable runtime pm.
To simplify the implementation, make the driver depend on PM as the
RPI5 platform where the ISP is integrated in uses the PM framework by
default.
Fixes: 12187bd5d4f8 ("media: raspberrypi: Add support for PiSP BE")
Cc: stable@vger.kernel.org
Tested-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
show more ...
|
| 972eed08 | 05-Aug-2024 |
Jacopo Mondi <jacopo.mondi@ideasonboard.com> |
media: pisp_be: Split jobs creation and scheduling
Currently the 'pispbe_schedule()' function does two things:
1) Tries to assemble a job by inspecting all the video node queues
to make sure all
media: pisp_be: Split jobs creation and scheduling
Currently the 'pispbe_schedule()' function does two things:
1) Tries to assemble a job by inspecting all the video node queues
to make sure all the required buffers are available
2) Submit the job to the hardware
The pispbe_schedule() function is called at:
- video device start_streaming() time
- video device qbuf() time
- irq handler
As assembling a job requires inspecting all queues, it is a rather
time consuming operation which is better not run in IRQ context.
To avoid executing the time consuming job creation in interrupt
context split the job creation and job scheduling in two distinct
operations. When a well-formed job is created, append it to the
newly introduced 'pispbe->job_queue' where it will be dequeued from
by the scheduling routine.
As the per-node 'ready_queue' buffer list is only accessed in vb2 ops
callbacks, protected by the node->queue_lock mutex, it is not necessary
to guard it with a dedicated spinlock so drop it. Also use the
spin_lock_irq() variant in all functions not called from an IRQ context
where the spin_lock_irqsave() version was used.
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
show more ...
|
| a773b614 | 26-Aug-2024 |
Jacopo Mondi <jacopo.mondi@ideasonboard.com> |
media: pisp_be: Remove config validation from schedule()
The config parameters buffer is already validated in
pisp_be_validate_config() at .buf_prepare() time.
However some of the same validations
media: pisp_be: Remove config validation from schedule()
The config parameters buffer is already validated in
pisp_be_validate_config() at .buf_prepare() time.
However some of the same validations are also performed at
pispbe_schedule() time. In particular the function checks that:
1) config.num_tiles is valid
2) At least one of the BAYER or RGB input is enabled
The input config validation is already performed in
pisp_be_validate_config() and while job.hw_enables is modified by
pispbe_xlate_addrs(), the function only resets the input masks if
- there is no input buffer available, but pispbe_prepare_job() fails
before calling pispbe_xlate_addrs() in this case
- bayer_enable is 0, but in this case rgb_enable is valid as guaranteed
by pisp_be_validate_config()
- only outputs are reset in rgb_enable
For this reasons there is no need to repeat the check at
pispbe_schedule() time.
The num_tiles validation can be moved to pisp_be_validate_config() as
well. As num_tiles is a u32 it can'be be < 0, so change the sanity
check accordingly.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
show more ...
|