Re: [PATCH v2 3/4] [media] bcm2835-unicam: Driver for CCP2/CSI2 camera interface
Hi Hans.
Thanks for the response.
On 19 September 2017 at 11:20, Hans Verkuil wrote:
> On 09/19/17 11:50, Dave Stevenson wrote:
>> Hi Eric.
>>
>> Thanks for the review.
>>
>> On 18 September 2017 at 19:18, Eric Anholt wrote:
>>> Dave Stevenson writes:
diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c
b/drivers/media/platform/bcm2835/bcm2835-unicam.c
new file mode 100644
index 000..5b1adc3
--- /dev/null
+++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
@@ -0,0 +1,2192 @@
+/*
+ * BCM2835 Unicam capture Driver
+ *
+ * Copyright (C) 2017 - Raspberry Pi (Trading) Ltd.
+ *
+ * Dave Stevenson
+ *
+ * Based on TI am437x driver by Benoit Parrot and Lad, Prabhakar and
+ * TI CAL camera interface driver by Benoit Parrot.
+ *
>>>
>>> Possible future improvement: this description of the driver is really
>>> nice and could be turned into kernel-doc.
>>
>> Documentation?! Surely not :-)
>> For now I'll leave it as a task for another day.
>>
+ * There are two camera drivers in the kernel for BCM283x - this one
+ * and bcm2835-camera (currently in staging).
+ *
+ * This driver is purely the kernel control the Unicam peripheral - there
>>>
>>> Maybe "This driver directly controls..."?
>>
>> Will do in v3.
>>
+ * is no involvement with the VideoCore firmware. Unicam receives CSI-2
+ * or CCP2 data and writes it into SDRAM. The only processing options are
+ * to repack Bayer data into an alternate format, and applying windowing
+ * (currently not implemented).
+ * It should be possible to connect it to any sensor with a
+ * suitable output interface and V4L2 subdevice driver.
+ *
+ * bcm2835-camera uses with the VideoCore firmware to control the sensor,
>>>
>>> "uses the"
>>
>> Will do in v3.
>>
+ * Unicam, ISP, and all tuner control loops. Fully processed frames are
+ * delivered to the driver by the firmware. It only has sensor drivers
+ * for Omnivision OV5647, and Sony IMX219 sensors.
+ *
+ * The two drivers are mutually exclusive for the same Unicam instance.
+ * The VideoCore firmware checks the device tree configuration during
boot.
+ * If it finds device tree nodes called csi0 or csi1 it will block the
+ * firmware from accessing the peripheral, and bcm2835-camera will
+ * not be able to stream data.
>>>
>>> Thanks for describing this here!
>>>
+/*
+ * The peripheral can unpack and repack between several of
+ * the Bayer raw formats, so any Bayer format can be advertised
+ * as the same Bayer order in each of the supported bit depths.
+ * Use lower case to avoid clashing with V4L2_PIX_FMT_SGBRG8
+ * formats.
+ */
+#define PIX_FMT_ALL_BGGR v4l2_fourcc('b', 'g', 'g', 'r')
+#define PIX_FMT_ALL_RGGB v4l2_fourcc('r', 'g', 'g', 'b')
+#define PIX_FMT_ALL_GBRG v4l2_fourcc('g', 'b', 'r', 'g')
+#define PIX_FMT_ALL_GRBG v4l2_fourcc('g', 'r', 'b', 'g')
>>>
>>> Should thes fourccs be defined in a common v4l2 header, to reserve it
>>> from clashing with others later?
>>
>> I'm only using them as flags and probably in a manner that nothing
>> else is likely to copy, so it seems a little excessive to put them in
>> a common header.
>> Perhaps it's better to switch to 0xFFF0 to 0xFFF3 or other
>> value that won't come up as a fourcc under any normal circumstance.
>> Any thoughts from other people?
>
> I think that's better, yes.
OK, happy to do that.
>>
>>> This is really the only question I have about this driver before seeing
>>> it merged. As far as me wearing my platform maintainer hat, I'm happy
>>> with the driver, and my other little notes are optional.
>>>
+static int unicam_probe(struct platform_device *pdev)
+{
+ struct unicam_cfg *unicam_cfg;
+ struct unicam_device *unicam;
+ struct v4l2_ctrl_handler *hdl;
+ struct resource *res;
+ int ret;
+
+ unicam = devm_kzalloc(&pdev->dev, sizeof(*unicam), GFP_KERNEL);
+ if (!unicam)
+ return -ENOMEM;
+
+ unicam->pdev = pdev;
+ unicam_cfg = &unicam->cfg;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ unicam_cfg->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(unicam_cfg->base)) {
+ unicam_err(unicam, "Failed to get main io block\n");
+ return PTR_ERR(unicam_cfg->base);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ unicam_cfg->clk_gate_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(unicam_cfg->clk_gate_base)) {
+ unicam_err(unicam, "Failed to get 2nd io block\n");
+ return PTR_ERR(unicam_cfg->clk_gate_base);
+ }
+
+ unicam->clock = devm_clk_get(&pdev->dev, "lp_clock");
Re: [PATCH v2 3/4] [media] bcm2835-unicam: Driver for CCP2/CSI2 camera interface
On 09/19/17 11:50, Dave Stevenson wrote:
> Hi Eric.
>
> Thanks for the review.
>
> On 18 September 2017 at 19:18, Eric Anholt wrote:
>> Dave Stevenson writes:
>>> diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c
>>> b/drivers/media/platform/bcm2835/bcm2835-unicam.c
>>> new file mode 100644
>>> index 000..5b1adc3
>>> --- /dev/null
>>> +++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
>>> @@ -0,0 +1,2192 @@
>>> +/*
>>> + * BCM2835 Unicam capture Driver
>>> + *
>>> + * Copyright (C) 2017 - Raspberry Pi (Trading) Ltd.
>>> + *
>>> + * Dave Stevenson
>>> + *
>>> + * Based on TI am437x driver by Benoit Parrot and Lad, Prabhakar and
>>> + * TI CAL camera interface driver by Benoit Parrot.
>>> + *
>>
>> Possible future improvement: this description of the driver is really
>> nice and could be turned into kernel-doc.
>
> Documentation?! Surely not :-)
> For now I'll leave it as a task for another day.
>
>>> + * There are two camera drivers in the kernel for BCM283x - this one
>>> + * and bcm2835-camera (currently in staging).
>>> + *
>>> + * This driver is purely the kernel control the Unicam peripheral - there
>>
>> Maybe "This driver directly controls..."?
>
> Will do in v3.
>
>>> + * is no involvement with the VideoCore firmware. Unicam receives CSI-2
>>> + * or CCP2 data and writes it into SDRAM. The only processing options are
>>> + * to repack Bayer data into an alternate format, and applying windowing
>>> + * (currently not implemented).
>>> + * It should be possible to connect it to any sensor with a
>>> + * suitable output interface and V4L2 subdevice driver.
>>> + *
>>> + * bcm2835-camera uses with the VideoCore firmware to control the sensor,
>>
>> "uses the"
>
> Will do in v3.
>
>>> + * Unicam, ISP, and all tuner control loops. Fully processed frames are
>>> + * delivered to the driver by the firmware. It only has sensor drivers
>>> + * for Omnivision OV5647, and Sony IMX219 sensors.
>>> + *
>>> + * The two drivers are mutually exclusive for the same Unicam instance.
>>> + * The VideoCore firmware checks the device tree configuration during boot.
>>> + * If it finds device tree nodes called csi0 or csi1 it will block the
>>> + * firmware from accessing the peripheral, and bcm2835-camera will
>>> + * not be able to stream data.
>>
>> Thanks for describing this here!
>>
>>> +/*
>>> + * The peripheral can unpack and repack between several of
>>> + * the Bayer raw formats, so any Bayer format can be advertised
>>> + * as the same Bayer order in each of the supported bit depths.
>>> + * Use lower case to avoid clashing with V4L2_PIX_FMT_SGBRG8
>>> + * formats.
>>> + */
>>> +#define PIX_FMT_ALL_BGGR v4l2_fourcc('b', 'g', 'g', 'r')
>>> +#define PIX_FMT_ALL_RGGB v4l2_fourcc('r', 'g', 'g', 'b')
>>> +#define PIX_FMT_ALL_GBRG v4l2_fourcc('g', 'b', 'r', 'g')
>>> +#define PIX_FMT_ALL_GRBG v4l2_fourcc('g', 'r', 'b', 'g')
>>
>> Should thes fourccs be defined in a common v4l2 header, to reserve it
>> from clashing with others later?
>
> I'm only using them as flags and probably in a manner that nothing
> else is likely to copy, so it seems a little excessive to put them in
> a common header.
> Perhaps it's better to switch to 0xFFF0 to 0xFFF3 or other
> value that won't come up as a fourcc under any normal circumstance.
> Any thoughts from other people?
I think that's better, yes.
>
>> This is really the only question I have about this driver before seeing
>> it merged. As far as me wearing my platform maintainer hat, I'm happy
>> with the driver, and my other little notes are optional.
>>
>>> +static int unicam_probe(struct platform_device *pdev)
>>> +{
>>> + struct unicam_cfg *unicam_cfg;
>>> + struct unicam_device *unicam;
>>> + struct v4l2_ctrl_handler *hdl;
>>> + struct resource *res;
>>> + int ret;
>>> +
>>> + unicam = devm_kzalloc(&pdev->dev, sizeof(*unicam), GFP_KERNEL);
>>> + if (!unicam)
>>> + return -ENOMEM;
>>> +
>>> + unicam->pdev = pdev;
>>> + unicam_cfg = &unicam->cfg;
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> + unicam_cfg->base = devm_ioremap_resource(&pdev->dev, res);
>>> + if (IS_ERR(unicam_cfg->base)) {
>>> + unicam_err(unicam, "Failed to get main io block\n");
>>> + return PTR_ERR(unicam_cfg->base);
>>> + }
>>> +
>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> + unicam_cfg->clk_gate_base = devm_ioremap_resource(&pdev->dev, res);
>>> + if (IS_ERR(unicam_cfg->clk_gate_base)) {
>>> + unicam_err(unicam, "Failed to get 2nd io block\n");
>>> + return PTR_ERR(unicam_cfg->clk_gate_base);
>>> + }
>>> +
>>> + unicam->clock = devm_clk_get(&pdev->dev, "lp_clock");
>>> + if (IS_ERR(unicam->clock)) {
>>> + unicam_err(unicam, "Failed to get clock\n");
>>> + return PTR_ERR(unicam->clock);
>>> + }
>>> +
>>> + ret = platform_get_irq(pdev, 0);
>>> + if (ret <
Re: [PATCH v2 3/4] [media] bcm2835-unicam: Driver for CCP2/CSI2 camera interface
Hi Eric.
Thanks for the review.
On 18 September 2017 at 19:18, Eric Anholt wrote:
> Dave Stevenson writes:
>> diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c
>> b/drivers/media/platform/bcm2835/bcm2835-unicam.c
>> new file mode 100644
>> index 000..5b1adc3
>> --- /dev/null
>> +++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
>> @@ -0,0 +1,2192 @@
>> +/*
>> + * BCM2835 Unicam capture Driver
>> + *
>> + * Copyright (C) 2017 - Raspberry Pi (Trading) Ltd.
>> + *
>> + * Dave Stevenson
>> + *
>> + * Based on TI am437x driver by Benoit Parrot and Lad, Prabhakar and
>> + * TI CAL camera interface driver by Benoit Parrot.
>> + *
>
> Possible future improvement: this description of the driver is really
> nice and could be turned into kernel-doc.
Documentation?! Surely not :-)
For now I'll leave it as a task for another day.
>> + * There are two camera drivers in the kernel for BCM283x - this one
>> + * and bcm2835-camera (currently in staging).
>> + *
>> + * This driver is purely the kernel control the Unicam peripheral - there
>
> Maybe "This driver directly controls..."?
Will do in v3.
>> + * is no involvement with the VideoCore firmware. Unicam receives CSI-2
>> + * or CCP2 data and writes it into SDRAM. The only processing options are
>> + * to repack Bayer data into an alternate format, and applying windowing
>> + * (currently not implemented).
>> + * It should be possible to connect it to any sensor with a
>> + * suitable output interface and V4L2 subdevice driver.
>> + *
>> + * bcm2835-camera uses with the VideoCore firmware to control the sensor,
>
> "uses the"
Will do in v3.
>> + * Unicam, ISP, and all tuner control loops. Fully processed frames are
>> + * delivered to the driver by the firmware. It only has sensor drivers
>> + * for Omnivision OV5647, and Sony IMX219 sensors.
>> + *
>> + * The two drivers are mutually exclusive for the same Unicam instance.
>> + * The VideoCore firmware checks the device tree configuration during boot.
>> + * If it finds device tree nodes called csi0 or csi1 it will block the
>> + * firmware from accessing the peripheral, and bcm2835-camera will
>> + * not be able to stream data.
>
> Thanks for describing this here!
>
>> +/*
>> + * The peripheral can unpack and repack between several of
>> + * the Bayer raw formats, so any Bayer format can be advertised
>> + * as the same Bayer order in each of the supported bit depths.
>> + * Use lower case to avoid clashing with V4L2_PIX_FMT_SGBRG8
>> + * formats.
>> + */
>> +#define PIX_FMT_ALL_BGGR v4l2_fourcc('b', 'g', 'g', 'r')
>> +#define PIX_FMT_ALL_RGGB v4l2_fourcc('r', 'g', 'g', 'b')
>> +#define PIX_FMT_ALL_GBRG v4l2_fourcc('g', 'b', 'r', 'g')
>> +#define PIX_FMT_ALL_GRBG v4l2_fourcc('g', 'r', 'b', 'g')
>
> Should thes fourccs be defined in a common v4l2 header, to reserve it
> from clashing with others later?
I'm only using them as flags and probably in a manner that nothing
else is likely to copy, so it seems a little excessive to put them in
a common header.
Perhaps it's better to switch to 0xFFF0 to 0xFFF3 or other
value that won't come up as a fourcc under any normal circumstance.
Any thoughts from other people?
> This is really the only question I have about this driver before seeing
> it merged. As far as me wearing my platform maintainer hat, I'm happy
> with the driver, and my other little notes are optional.
>
>> +static int unicam_probe(struct platform_device *pdev)
>> +{
>> + struct unicam_cfg *unicam_cfg;
>> + struct unicam_device *unicam;
>> + struct v4l2_ctrl_handler *hdl;
>> + struct resource *res;
>> + int ret;
>> +
>> + unicam = devm_kzalloc(&pdev->dev, sizeof(*unicam), GFP_KERNEL);
>> + if (!unicam)
>> + return -ENOMEM;
>> +
>> + unicam->pdev = pdev;
>> + unicam_cfg = &unicam->cfg;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + unicam_cfg->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(unicam_cfg->base)) {
>> + unicam_err(unicam, "Failed to get main io block\n");
>> + return PTR_ERR(unicam_cfg->base);
>> + }
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> + unicam_cfg->clk_gate_base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(unicam_cfg->clk_gate_base)) {
>> + unicam_err(unicam, "Failed to get 2nd io block\n");
>> + return PTR_ERR(unicam_cfg->clk_gate_base);
>> + }
>> +
>> + unicam->clock = devm_clk_get(&pdev->dev, "lp_clock");
>> + if (IS_ERR(unicam->clock)) {
>> + unicam_err(unicam, "Failed to get clock\n");
>> + return PTR_ERR(unicam->clock);
>> + }
>> +
>> + ret = platform_get_irq(pdev, 0);
>> + if (ret <= 0) {
>> + dev_err(&pdev->dev, "No IRQ resource\n");
>> + return -ENODEV;
>> + }
>> + unicam_cfg->irq = ret;
>> +
>> + ret = devm_request_irq(&pdev->dev, unicam_cfg->irq, unicam_isr, 0
Re: [PATCH v2 3/4] [media] bcm2835-unicam: Driver for CCP2/CSI2 camera interface
Dave Stevenson writes:
> diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c
> b/drivers/media/platform/bcm2835/bcm2835-unicam.c
> new file mode 100644
> index 000..5b1adc3
> --- /dev/null
> +++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
> @@ -0,0 +1,2192 @@
> +/*
> + * BCM2835 Unicam capture Driver
> + *
> + * Copyright (C) 2017 - Raspberry Pi (Trading) Ltd.
> + *
> + * Dave Stevenson
> + *
> + * Based on TI am437x driver by Benoit Parrot and Lad, Prabhakar and
> + * TI CAL camera interface driver by Benoit Parrot.
> + *
Possible future improvement: this description of the driver is really
nice and could be turned into kernel-doc.
> + * There are two camera drivers in the kernel for BCM283x - this one
> + * and bcm2835-camera (currently in staging).
> + *
> + * This driver is purely the kernel control the Unicam peripheral - there
Maybe "This driver directly controls..."?
> + * is no involvement with the VideoCore firmware. Unicam receives CSI-2
> + * or CCP2 data and writes it into SDRAM. The only processing options are
> + * to repack Bayer data into an alternate format, and applying windowing
> + * (currently not implemented).
> + * It should be possible to connect it to any sensor with a
> + * suitable output interface and V4L2 subdevice driver.
> + *
> + * bcm2835-camera uses with the VideoCore firmware to control the sensor,
"uses the"
> + * Unicam, ISP, and all tuner control loops. Fully processed frames are
> + * delivered to the driver by the firmware. It only has sensor drivers
> + * for Omnivision OV5647, and Sony IMX219 sensors.
> + *
> + * The two drivers are mutually exclusive for the same Unicam instance.
> + * The VideoCore firmware checks the device tree configuration during boot.
> + * If it finds device tree nodes called csi0 or csi1 it will block the
> + * firmware from accessing the peripheral, and bcm2835-camera will
> + * not be able to stream data.
Thanks for describing this here!
> +/*
> + * The peripheral can unpack and repack between several of
> + * the Bayer raw formats, so any Bayer format can be advertised
> + * as the same Bayer order in each of the supported bit depths.
> + * Use lower case to avoid clashing with V4L2_PIX_FMT_SGBRG8
> + * formats.
> + */
> +#define PIX_FMT_ALL_BGGR v4l2_fourcc('b', 'g', 'g', 'r')
> +#define PIX_FMT_ALL_RGGB v4l2_fourcc('r', 'g', 'g', 'b')
> +#define PIX_FMT_ALL_GBRG v4l2_fourcc('g', 'b', 'r', 'g')
> +#define PIX_FMT_ALL_GRBG v4l2_fourcc('g', 'r', 'b', 'g')
Should thes fourccs be defined in a common v4l2 header, to reserve it
from clashing with others later?
This is really the only question I have about this driver before seeing
it merged. As far as me wearing my platform maintainer hat, I'm happy
with the driver, and my other little notes are optional.
> +static int unicam_probe(struct platform_device *pdev)
> +{
> + struct unicam_cfg *unicam_cfg;
> + struct unicam_device *unicam;
> + struct v4l2_ctrl_handler *hdl;
> + struct resource *res;
> + int ret;
> +
> + unicam = devm_kzalloc(&pdev->dev, sizeof(*unicam), GFP_KERNEL);
> + if (!unicam)
> + return -ENOMEM;
> +
> + unicam->pdev = pdev;
> + unicam_cfg = &unicam->cfg;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + unicam_cfg->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(unicam_cfg->base)) {
> + unicam_err(unicam, "Failed to get main io block\n");
> + return PTR_ERR(unicam_cfg->base);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + unicam_cfg->clk_gate_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(unicam_cfg->clk_gate_base)) {
> + unicam_err(unicam, "Failed to get 2nd io block\n");
> + return PTR_ERR(unicam_cfg->clk_gate_base);
> + }
> +
> + unicam->clock = devm_clk_get(&pdev->dev, "lp_clock");
> + if (IS_ERR(unicam->clock)) {
> + unicam_err(unicam, "Failed to get clock\n");
> + return PTR_ERR(unicam->clock);
> + }
> +
> + ret = platform_get_irq(pdev, 0);
> + if (ret <= 0) {
> + dev_err(&pdev->dev, "No IRQ resource\n");
> + return -ENODEV;
> + }
> + unicam_cfg->irq = ret;
> +
> + ret = devm_request_irq(&pdev->dev, unicam_cfg->irq, unicam_isr, 0,
> +"unicam_capture0", unicam);
Looks like there's no need to keep "irq" in the device private struct.
> + if (ret) {
> + dev_err(&pdev->dev, "Unable to request interrupt\n");
> + return -EINVAL;
> + }
> +
> + ret = v4l2_device_register(&pdev->dev, &unicam->v4l2_dev);
> + if (ret) {
> + unicam_err(unicam,
> +"Unable to register v4l2 device.\n");
> + return ret;
> + }
> +
> + /* Reserve space for the controls */
> + hdl = &unicam->ctrl_handler;
> + ret = v4l2_ctrl_handler_init(hdl, 16);
> + if (ret
[PATCH v2 3/4] [media] bcm2835-unicam: Driver for CCP2/CSI2 camera interface
Add driver for the Unicam camera receiver block on BCM283x processors. Signed-off-by: Dave Stevenson --- drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile |1 + drivers/media/platform/bcm2835/Kconfig | 14 + drivers/media/platform/bcm2835/Makefile |3 + drivers/media/platform/bcm2835/bcm2835-unicam.c | 2192 ++ drivers/media/platform/bcm2835/vc4-regs-unicam.h | 264 +++ 6 files changed, 2475 insertions(+) create mode 100644 drivers/media/platform/bcm2835/Kconfig create mode 100644 drivers/media/platform/bcm2835/Makefile create mode 100644 drivers/media/platform/bcm2835/bcm2835-unicam.c create mode 100644 drivers/media/platform/bcm2835/vc4-regs-unicam.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 7e7cc49..1e5f004 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -150,6 +150,7 @@ source "drivers/media/platform/am437x/Kconfig" source "drivers/media/platform/xilinx/Kconfig" source "drivers/media/platform/rcar-vin/Kconfig" source "drivers/media/platform/atmel/Kconfig" +source "drivers/media/platform/bcm2835/Kconfig" config VIDEO_TI_CAL tristate "TI CAL (Camera Adaptation Layer) driver" diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index c1ef946..045de3f 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -90,3 +90,4 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= qcom/camss-8x16/ obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/ obj-y += meson/ +obj-y += bcm2835/ diff --git a/drivers/media/platform/bcm2835/Kconfig b/drivers/media/platform/bcm2835/Kconfig new file mode 100644 index 000..6a74842 --- /dev/null +++ b/drivers/media/platform/bcm2835/Kconfig @@ -0,0 +1,14 @@ +# Broadcom VideoCore4 V4L2 camera support + +config VIDEO_BCM2835_UNICAM + tristate "Broadcom BCM2835 Unicam video capture driver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + depends on ARCH_BCM2835 || COMPILE_TEST + select VIDEOBUF2_DMA_CONTIG + select V4L2_FWNODE + ---help--- + Say Y here to enable V4L2 subdevice for CSI2 receiver. + This is a V4L2 subdevice that interfaces directly to the VC4 peripheral. + + To compile this driver as a module, choose M here. The module + will be called bcm2835-unicam. diff --git a/drivers/media/platform/bcm2835/Makefile b/drivers/media/platform/bcm2835/Makefile new file mode 100644 index 000..a98aba0 --- /dev/null +++ b/drivers/media/platform/bcm2835/Makefile @@ -0,0 +1,3 @@ +# Makefile for BCM2835 Unicam driver + +obj-$(CONFIG_VIDEO_BCM2835_UNICAM) += bcm2835-unicam.o diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c b/drivers/media/platform/bcm2835/bcm2835-unicam.c new file mode 100644 index 000..5b1adc3 --- /dev/null +++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c @@ -0,0 +1,2192 @@ +/* + * BCM2835 Unicam capture Driver + * + * Copyright (C) 2017 - Raspberry Pi (Trading) Ltd. + * + * Dave Stevenson + * + * Based on TI am437x driver by Benoit Parrot and Lad, Prabhakar and + * TI CAL camera interface driver by Benoit Parrot. + * + * + * There are two camera drivers in the kernel for BCM283x - this one + * and bcm2835-camera (currently in staging). + * + * This driver is purely the kernel control the Unicam peripheral - there + * is no involvement with the VideoCore firmware. Unicam receives CSI-2 + * or CCP2 data and writes it into SDRAM. The only processing options are + * to repack Bayer data into an alternate format, and applying windowing + * (currently not implemented). + * It should be possible to connect it to any sensor with a + * suitable output interface and V4L2 subdevice driver. + * + * bcm2835-camera uses with the VideoCore firmware to control the sensor, + * Unicam, ISP, and all tuner control loops. Fully processed frames are + * delivered to the driver by the firmware. It only has sensor drivers + * for Omnivision OV5647, and Sony IMX219 sensors. + * + * The two drivers are mutually exclusive for the same Unicam instance. + * The VideoCore firmware checks the device tree configuration during boot. + * If it finds device tree nodes called csi0 or csi1 it will block the + * firmware from accessing the peripheral, and bcm2835-camera will + * not be able to stream data. + * + * + * This program is free software; you may redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDER
