libcamera: Rationalize IPA and handlers names

The names used by the IPA interface and the names used for buffer
completions handlers in libcamera clash in the use of the term "buffer".

For example video device buffer completion handler is called
"bufferReady" and the IPA event to ask the IPA to compute parameters are
called "fillParamsBuffers". This makes it hard to recognize which
function handles video device completion signals and which ones handle
the IPA interface events.

Rationalize the naming scheme in the IPA interface function and events
and the signal handlers in the pipelines,  according to the
following table. Remove the name "buffer" from the IPA interface events
and events handler and reserve it for the buffer completion handlers.
Rename the IPA interface events and function to use the 'params' and
'stats' names as well.

IPA Interface:

- fillParamsBuffer -> computeParams   [FUNCTION]
- processStatsBuffer -> processStats  [FUNCTION]
- paramFilled -> paramsComputed       [EVENT]

Pipeline handler:

- bufferReady -> videoBufferReady     [BUFFER HANDLER]
- paramReady -> paramBufferReady      [BUFFER HANDLER]
- statReady -> statBufferReady        [BUFFER HANDLER]
- paramFilled -> paramsComputed       [IPA EVENT HANDLER]

Cosmetic change only, no functional changes intended.

Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>

2 files changed, 19 insertions, 19 deletions

diff --git a/src/ipa/ipu3/ipu3-ipa-design-guide.rst b/src/ipa/ipu3/ipu3-ipa-design-guide.rst
index 72506397..85d735c6 100644
--- a/src/ipa/ipu3/ipu3-ipa-design-guide.rst
+++ b/src/ipa/ipu3/ipu3-ipa-design-guide.rst
@@ -27,8 +27,8 @@ from applications, and managing events from the pipeline handler.
       └─┬───┬───┬──────┬────┬────┬────┬─┴────▼─┬──┘    1: init()
         │   │   │      │ ▲  │ ▲  │ ▲  │ ▲      │       2: configure()
         │1  │2  │3     │4│  │4│  │4│  │4│      │5      3: mapBuffers(), start()
-        │   │   │      │ │  │ │  │ │  │ │      │       4: (▼) queueRequest(), fillParamsBuffer(), processStatsBuffer()
-        ▼   ▼   ▼      ▼ │  ▼ │  ▼ │  ▼ │      ▼          (▲) setSensorControls, paramsBufferReady, metadataReady Signals
+        │   │   │      │ │  │ │  │ │  │ │      │       4: (▼) queueRequest(), computeParams(), processStats()
+        ▼   ▼   ▼      ▼ │  ▼ │  ▼ │  ▼ │      ▼          (▲) setSensorControls, paramsComputed, metadataReady Signals
       ┌──────────────────┴────┴────┴────┴─────────┐    5: stop(), unmapBuffers()
       │ IPU3 IPA                                  │
       │                 ┌───────────────────────┐ │
@@ -104,8 +104,8 @@ to operate when running:
 
 -  configure()
 -  queueRequest()
--  fillParamsBuffer()
--  processStatsBuffer()
+-  computeParams()
+-  processStats()
 
 The configuration phase allows the pipeline-handler to inform the IPA of
 the current stream configurations, which is then passed into each
@@ -119,7 +119,7 @@ When configured, the IPA is notified by the pipeline handler of the
 Camera ``start()`` event, after which incoming requests will be queued
 for processing, requiring a parameter buffer (``ipu3_uapi_params``) to
 be populated for the ImgU. This is given to the IPA through
-``fillParamsBuffer()``, and then passed directly to each algorithm
+``computeParams()``, and then passed directly to each algorithm
 through the ``prepare()`` call allowing the ISP configuration to be
 updated for the needs of each component that the algorithm is
 responsible for.
@@ -129,7 +129,7 @@ structure that it modifies, and it should take care to ensure that any
 structure set by a use flag is fully initialised to suitable values.
 
 The parameter buffer is returned to the pipeline handler through the
-``paramsBufferReady`` signal, and from there queued to the ImgU along
+``paramsComputed`` signal, and from there queued to the ImgU along
 with a raw frame captured with the CIO2.
 
 Post-frame completion
@@ -138,7 +138,7 @@ Post-frame completion
 When the capture of an image is completed, and successfully processed
 through the ImgU, the generated statistics buffer
 (``ipu3_uapi_stats_3a``) is given to the IPA through
-``processStatsBuffer()``. This provides the IPA with an opportunity to
+``processStats()``. This provides the IPA with an opportunity to
 examine the results of the ISP and run the calculations required by each
 algorithm on the new data. The algorithms may require context from the
 operations of other algorithms, for example, the AWB might choose to use
diff --git a/src/ipa/ipu3/ipu3.cpp b/src/ipa/ipu3/ipu3.cpp
index 10a8c86d..89c3192c 100644
--- a/src/ipa/ipu3/ipu3.cpp
+++ b/src/ipa/ipu3/ipu3.cpp
@@ -87,14 +87,14 @@ namespace ipa::ipu3 {
  * parameter buffer, and adapting the settings of the sensor attached to the
  * IPU3 CIO2 through sensor-specific V4L2 controls.
  *
- * In fillParamsBuffer(), we populate the ImgU parameter buffer with
+ * In computeParams(), we populate the ImgU parameter buffer with
  * settings to configure the device in preparation for handling the frame
  * queued in the Request.
  *
  * When the frame has completed processing, the ImgU will generate a statistics
- * buffer which is given to the IPA with processStatsBuffer(). In this we run the
+ * buffer which is given to the IPA with processStats(). In this we run the
  * algorithms to parse the statistics and cache any results for the next
- * fillParamsBuffer() call.
+ * computeParams() call.
  *
  * The individual algorithms are split into modular components that are called
  * iteratively to allow them to process statistics from the ImgU in the order
@@ -155,10 +155,10 @@ public:
 	void unmapBuffers(const std::vector<unsigned int> &ids) override;
 
 	void queueRequest(const uint32_t frame, const ControlList &controls) override;
-	void fillParamsBuffer(const uint32_t frame, const uint32_t bufferId) override;
-	void processStatsBuffer(const uint32_t frame, const int64_t frameTimestamp,
-				const uint32_t bufferId,
-				const ControlList &sensorControls) override;
+	void computeParams(const uint32_t frame, const uint32_t bufferId) override;
+	void processStats(const uint32_t frame, const int64_t frameTimestamp,
+			  const uint32_t bufferId,
+			  const ControlList &sensorControls) override;
 
 protected:
 	std::string logPrefix() const override;
@@ -538,7 +538,7 @@ void IPAIPU3::unmapBuffers(const std::vector<unsigned int> &ids)
  * Algorithms are expected to fill the IPU3 parameter buffer for the next
  * frame given their most recent processing of the ImgU statistics.
  */
-void IPAIPU3::fillParamsBuffer(const uint32_t frame, const uint32_t bufferId)
+void IPAIPU3::computeParams(const uint32_t frame, const uint32_t bufferId)
 {
 	auto it = buffers_.find(bufferId);
 	if (it == buffers_.end()) {
@@ -566,7 +566,7 @@ void IPAIPU3::fillParamsBuffer(const uint32_t frame, const uint32_t bufferId)
 	for (auto const &algo : algorithms())
 		algo->prepare(context_, frame, frameContext, params);
 
-	paramsBufferReady.emit(frame);
+	paramsComputed.emit(frame);
 }
 
 /**
@@ -580,9 +580,9 @@ void IPAIPU3::fillParamsBuffer(const uint32_t frame, const uint32_t bufferId)
  * statistics are passed to each algorithm module to run their calculations and
  * update their state accordingly.
  */
-void IPAIPU3::processStatsBuffer(const uint32_t frame,
-				 [[maybe_unused]] const int64_t frameTimestamp,
-				 const uint32_t bufferId, const ControlList &sensorControls)
+void IPAIPU3::processStats(const uint32_t frame,
+			   [[maybe_unused]] const int64_t frameTimestamp,
+			   const uint32_t bufferId, const ControlList &sensorControls)
 {
 	auto it = buffers_.find(bufferId);
 	if (it == buffers_.end()) {