Commits on Sep 4, 2024

1. media: pisp_be: Drop reference to non-existing function …

   A comment in the pisp_be driver references the
   pispbe_schedule_internal() function which doesn't exist.
   
   Drop it.
   
   Signed-off-by: Jacopo Mondi <[email protected]>
   Reviewed-by: Laurent Pinchart <[email protected]>

   Jacopo Mondi committed Sep 4, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 3d0623d
   • Browse repository at this point

   Copy the full SHA

   3d0623d View commit details

   Browse the repository at this point in the history

2. 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.
   
   Signed-off-by: Jacopo Mondi <[email protected]>
   Reviewed-by: Laurent Pinchart <[email protected]>

   Jacopo Mondi committed Sep 4, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for e6ab8e2
   • Browse repository at this point

   Copy the full SHA

   e6ab8e2 View commit details

   Browse the repository at this point in the history

3. 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 the 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 a 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.
   
   Signed-off-by: Jacopo Mondi <[email protected]>

   Jacopo Mondi committed Sep 4, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 0ea92dc
   • Browse repository at this point

   Copy the full SHA

   0ea92dc View commit details

   Browse the repository at this point in the history

4. media: pisp_be: Fix pm_runtime underrun in probe …

   During the probe() routine, the driver needs to power up the interface
   in order to identify and initialize the hardware and it later suspends
   it at the end of probe().
   
   The driver erroneously resumes the interface by calling the
   pispbe_runtime_resume() function directly but 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 suspending the interface using pm_runtime_idle() which
   doesn't decrease the pm_runtime usage count and inform the PM framework
   that the device is active by calling pm_runtime_set_active().
   
   Adjust the pispbe_remove() function as well to disable
   the pm_runtime in the correct order.
   
   Signed-off-by: Jacopo Mondi <[email protected]>
   Reviewed-by: Laurent Pinchart <[email protected]>
   
   ---
   v4->v5:
   - Indent with tabs :/
   
   v3->v4:
   - Instead of using pm_runtime for resuming, suspend using
     pm_runtime_idle() to support !CONFIG_PM
   
   v2->v3:
   - Mark pispbe_runtime_resume() as __maybe_unused as reported by
     the kernel test robot <[email protected]>

   Jacopo Mondi committed Sep 4, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 775912b
   • Browse repository at this point

   Copy the full SHA

   775912b View commit details

   Browse the repository at this point in the history