mbox series

[0/4] media: raspberrypi: Support RPi5's CFE

Message ID 20240318-rp1-cfe-v1-0-ac6d960ff22d@ideasonboard.com
Headers show
Series media: raspberrypi: Support RPi5's CFE | expand

Message

Tomi Valkeinen March 18, 2024, 3:49 p.m. UTC
This series adds support to the CFE hardware block on RaspberryPi 5. The
CFE (Camera Front End) contains a CSI-2 receiver and Front End, a small
ISP.

This series is currently based on multiple other serieses:

- Sakari's "[PATCH v8 00/38] Generic line based metadata support, internal
  pads" for metadata support
- Laurent's "[PATCH 00/15] media: Add driver for the Raspberry Pi <5
  CSI-2 receiver" for a few new pixel formats and imx219 (for testing).
- Jacopo's "[PATCH v5 0/9] media: raspberrypi: Add support for PiSP Back
  End" for some shared uapi headers.

And to run this, one of course needs the basic RPi5 kernel support plus
relevant dts changes to enable the cfe and camera.

So at the moment we cannot merge this driver, but hopefully the
dependencies will get merged before the reviews on this one are done.

A few notes about the patches:

- The original work was done by RaspberryPi, mostly by Naushir Patuck.
- The second video node only sets V4L2_CAP_META_CAPTURE instead of both
  V4L2_CAP_META_CAPTURE and V4L2_CAP_META_CAPTURE like the other nodes.
  This is a temporary workaround for userspace (libcamera), and
  hopefully can be removed soon.
- The compatible string is set to "raspberrypi,rpi5-rp1-cfe". I added
  the "rpi5" part as versioning, as there's no clear CFE hardware
  version defined. I'm open to other suggestions on the versioning
  scheme.

I have tested this with:
- A single IMX219 sensor connected to the RPi5's CSI-2 port
- Arducam's UB960 FPD-Link board with four imx219 sensors connected

I have pushed my branch, with all the dependencies and everything needed
to run this, to:

git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git rp1-cfe

 Tomi

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Tomi Valkeinen (4):
      media: uapi: Add meta formats for PiSP FE config and stats
      dt-bindings: media: Add bindings for raspberrypi,rp1-cfe
      media: raspberrypi: Add support for RP1-CFE
      media: admin-guide: Document the Raspberry Pi CFE (rp1-cfe)

 .../admin-guide/media/raspberrypi-rp1-cfe.dot      |   27 +
 .../admin-guide/media/raspberrypi-rp1-cfe.rst      |   78 +
 Documentation/admin-guide/media/v4l-drivers.rst    |    1 +
 .../bindings/media/raspberrypi,rp1-cfe.yaml        |  103 +
 .../userspace-api/media/v4l/meta-formats.rst       |    1 +
 .../userspace-api/media/v4l/metafmt-pisp-fe.rst    |   39 +
 MAINTAINERS                                        |    8 +
 drivers/media/platform/raspberrypi/Kconfig         |    1 +
 drivers/media/platform/raspberrypi/Makefile        |    1 +
 drivers/media/platform/raspberrypi/rp1-cfe/Kconfig |   14 +
 .../media/platform/raspberrypi/rp1-cfe/Makefile    |    6 +
 .../media/platform/raspberrypi/rp1-cfe/cfe-fmts.h  |  330 +++
 .../media/platform/raspberrypi/rp1-cfe/cfe-trace.h |  196 ++
 drivers/media/platform/raspberrypi/rp1-cfe/cfe.c   | 2526 ++++++++++++++++++++
 drivers/media/platform/raspberrypi/rp1-cfe/cfe.h   |   43 +
 drivers/media/platform/raspberrypi/rp1-cfe/csi2.c  |  579 +++++
 drivers/media/platform/raspberrypi/rp1-cfe/csi2.h  |   89 +
 drivers/media/platform/raspberrypi/rp1-cfe/dphy.c  |  175 ++
 drivers/media/platform/raspberrypi/rp1-cfe/dphy.h  |   27 +
 .../media/platform/raspberrypi/rp1-cfe/pisp-fe.c   |  581 +++++
 .../media/platform/raspberrypi/rp1-cfe/pisp-fe.h   |   53 +
 drivers/media/v4l2-core/v4l2-ioctl.c               |    2 +
 .../uapi/linux/media/raspberrypi/pisp_fe_config.h  |  273 +++
 .../linux/media/raspberrypi/pisp_fe_statistics.h   |   64 +
 include/uapi/linux/videodev2.h                     |    2 +
 25 files changed, 5219 insertions(+)
---
base-commit: d87156e95652bc6463f86b25149f75cc3b8742eb
change-id: 20240314-rp1-cfe-142b628b7214

Best regards,

Comments

Krzysztof Kozlowski March 19, 2024, 6:05 a.m. UTC | #1
On 18/03/2024 16:49, Tomi Valkeinen wrote:
> This series adds support to the CFE hardware block on RaspberryPi 5. The
> CFE (Camera Front End) contains a CSI-2 receiver and Front End, a small
> ISP.
> 
> This series is currently based on multiple other serieses:
> 
> - Sakari's "[PATCH v8 00/38] Generic line based metadata support, internal
>   pads" for metadata support
> - Laurent's "[PATCH 00/15] media: Add driver for the Raspberry Pi <5
>   CSI-2 receiver" for a few new pixel formats and imx219 (for testing).
> - Jacopo's "[PATCH v5 0/9] media: raspberrypi: Add support for PiSP Back
>   End" for some shared uapi headers.
> 
> And to run this, one of course needs the basic RPi5 kernel support plus
> relevant dts changes to enable the cfe and camera.

Which makes it impossible to merge. Please work on decoupling.

Best regards,
Krzysztof
Tomi Valkeinen March 19, 2024, 6:21 a.m. UTC | #2
Hi,

On 19/03/2024 08:05, Krzysztof Kozlowski wrote:
> On 18/03/2024 16:49, Tomi Valkeinen wrote:
>> This series adds support to the CFE hardware block on RaspberryPi 5. The
>> CFE (Camera Front End) contains a CSI-2 receiver and Front End, a small
>> ISP.
>>
>> This series is currently based on multiple other serieses:
>>
>> - Sakari's "[PATCH v8 00/38] Generic line based metadata support, internal
>>    pads" for metadata support
>> - Laurent's "[PATCH 00/15] media: Add driver for the Raspberry Pi <5
>>    CSI-2 receiver" for a few new pixel formats and imx219 (for testing).
>> - Jacopo's "[PATCH v5 0/9] media: raspberrypi: Add support for PiSP Back
>>    End" for some shared uapi headers.
>>
>> And to run this, one of course needs the basic RPi5 kernel support plus
>> relevant dts changes to enable the cfe and camera.
> 
> Which makes it impossible to merge. Please work on decoupling.

Yes, it's not for merging as I wrote: "So at the moment we cannot merge 
this driver, but hopefully the dependencies will get merged before the 
reviews on this one are done."

I believe Sakari's and Jacopo's serieses should be very close to 
merging, and those should satisfy the needs of the driver itself.

The DT bindings example uses a header from RPi5 base support series, and 
if merging the base support seems to take a long time, I guess I could 
drop the include and just use numbers instead for RP1_INT_MIPI0 and 
RP1_CLK_MIPI0_CFG. And change those back later when the base support is 
merged.

  Tomi
Krzysztof Kozlowski March 19, 2024, 6:23 a.m. UTC | #3
On 19/03/2024 07:21, Tomi Valkeinen wrote:
> Hi,
> 
> On 19/03/2024 08:05, Krzysztof Kozlowski wrote:
>> On 18/03/2024 16:49, Tomi Valkeinen wrote:
>>> This series adds support to the CFE hardware block on RaspberryPi 5. The
>>> CFE (Camera Front End) contains a CSI-2 receiver and Front End, a small
>>> ISP.
>>>
>>> This series is currently based on multiple other serieses:
>>>
>>> - Sakari's "[PATCH v8 00/38] Generic line based metadata support, internal
>>>    pads" for metadata support
>>> - Laurent's "[PATCH 00/15] media: Add driver for the Raspberry Pi <5
>>>    CSI-2 receiver" for a few new pixel formats and imx219 (for testing).
>>> - Jacopo's "[PATCH v5 0/9] media: raspberrypi: Add support for PiSP Back
>>>    End" for some shared uapi headers.
>>>
>>> And to run this, one of course needs the basic RPi5 kernel support plus
>>> relevant dts changes to enable the cfe and camera.
>>
>> Which makes it impossible to merge. Please work on decoupling.
> 
> Yes, it's not for merging as I wrote: "So at the moment we cannot merge 
> this driver, but hopefully the dependencies will get merged before the 
> reviews on this one are done."
> 
> I believe Sakari's and Jacopo's serieses should be very close to 
> merging, and those should satisfy the needs of the driver itself.
> 
> The DT bindings example uses a header from RPi5 base support series, and 
> if merging the base support seems to take a long time, I guess I could 
> drop the include and just use numbers instead for RP1_INT_MIPI0 and 
> RP1_CLK_MIPI0_CFG. And change those back later when the base support is 
> merged.

The problem is that your patches cannot be tested by automated tools.

Best regards,
Krzysztof
Tomi Valkeinen March 19, 2024, 6:29 a.m. UTC | #4
On 19/03/2024 08:23, Krzysztof Kozlowski wrote:
> On 19/03/2024 07:21, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 19/03/2024 08:05, Krzysztof Kozlowski wrote:
>>> On 18/03/2024 16:49, Tomi Valkeinen wrote:
>>>> This series adds support to the CFE hardware block on RaspberryPi 5. The
>>>> CFE (Camera Front End) contains a CSI-2 receiver and Front End, a small
>>>> ISP.
>>>>
>>>> This series is currently based on multiple other serieses:
>>>>
>>>> - Sakari's "[PATCH v8 00/38] Generic line based metadata support, internal
>>>>     pads" for metadata support
>>>> - Laurent's "[PATCH 00/15] media: Add driver for the Raspberry Pi <5
>>>>     CSI-2 receiver" for a few new pixel formats and imx219 (for testing).
>>>> - Jacopo's "[PATCH v5 0/9] media: raspberrypi: Add support for PiSP Back
>>>>     End" for some shared uapi headers.
>>>>
>>>> And to run this, one of course needs the basic RPi5 kernel support plus
>>>> relevant dts changes to enable the cfe and camera.
>>>
>>> Which makes it impossible to merge. Please work on decoupling.
>>
>> Yes, it's not for merging as I wrote: "So at the moment we cannot merge
>> this driver, but hopefully the dependencies will get merged before the
>> reviews on this one are done."
>>
>> I believe Sakari's and Jacopo's serieses should be very close to
>> merging, and those should satisfy the needs of the driver itself.
>>
>> The DT bindings example uses a header from RPi5 base support series, and
>> if merging the base support seems to take a long time, I guess I could
>> drop the include and just use numbers instead for RP1_INT_MIPI0 and
>> RP1_CLK_MIPI0_CFG. And change those back later when the base support is
>> merged.
> 
> The problem is that your patches cannot be tested by automated tools.

Yes, I understand. I will send testable and mergeable patches when the 
dependencies are in, and until that this series is do-not-merge. But as 
reviews sometimes take a very long time, I think it's better to start 
sooner than later.

Is there a way to mark a series as "don't bother testing" for automated 
tools? RFC in the subject? I considered making this RFC, but I felt the 
patches themselves are not RFC quality. I've also seen DNI 
(do-not-integrate) used somewhere, but I'm not sure that's universally 
understood.

  Tomi