[PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Mauro Carvalho Chehab]

Em Wed, 15 Mar 2017 15:01:29 -0700
Eric Anholt <eric at anholt.net> escreveu:

> Mauro Carvalho Chehab <mchehab at s-opensource.com> writes:
> 
> > Em Fri, 27 Jan 2017 13:54:57 -0800
> > Eric Anholt <eric at anholt.net> escreveu:
> >  
> >> Here's my first pass at importing the camera driver.  There's a bunch
> >> of TODO left to it, most of which is documented, and the rest being
> >> standard checkpatch fare.
> >> 
> >> Unfortunately, when I try modprobing it on my pi3, the USB network
> >> device dies, consistently.  I'm not sure what's going on here yet, but
> >> I'm going to keep working on some debug of it.  I've unfortunately
> >> changed a lot of variables (pi3 vs pi2, upstream vs downstream, vchi's
> >> updates while in staging, 4.9 vs 4.4), so I probably won't figure it
> >> out today.
> >> 
> >> Note that the "Update the driver to the current VCHI API" patch will
> >> conflict with the outstanding "Add vchi_queue_kernel_message and
> >> vchi_queue_user_message" series, but the fix should be pretty obvious
> >> when that lands.
> >> 
> >> I built this against 4.10-rc1, but a merge with staging-next was clean
> >> and still built fine.  
> >
> > I'm trying it, building from the linux-next branch of the staging
> > tree. No joy.
> >
> > That's what happens when I modprobe it:
> >
> > [  991.841549] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
> > [  991.842931] vchiq_get_state: g_state.remote == NULL
> > [  991.843437] vchiq_get_state: g_state.remote == NULL
> > [  991.843940] vchiq_get_state: g_state.remote == NULL
> > [  991.844444] vchiq_get_state: g_state.remote == NULL
> > [  991.844947] vchiq_get_state: g_state.remote == NULL
> > [  991.845451] vchiq_get_state: g_state.remote == NULL
> > [  991.845954] vchiq_get_state: g_state.remote == NULL
> > [  991.846457] vchiq_get_state: g_state.remote == NULL
> > [  991.846961] vchiq_get_state: g_state.remote == NULL
> > [  991.847464] vchiq_get_state: g_state.remote == NULL
> > [  991.847969] vchiq: vchiq_initialise: videocore not initialized
> >
> > [  991.847973] mmal_vchiq: Failed to initialise VCHI instance (status=-1)  
> 
> Yeah, this failure mode sucks.  I'm guessing you don't have a VCHI node
> in the DT?  Patch attached.

No, I didn't. Thanks! Applied it but, unfortunately, didn't work.
Perhaps I'm missing some other patch. I'm compiling it from
the Greg's staging tree (branch staging-next):
	https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/log/?h=staging-next

Btw, as I'm running Raspbian, and didn't want to use compat32 bits, 
I'm compiling the Kernel as an arm32 bits Kernel.

I did a small trick to build the DTB on arm32:

	ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts arch/arm/boot/dts/bcm2837-rpi-3-b.dts
	ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi arch/arm/boot/dts/bcm2837.dtsi
	git checkout arch/arm/boot/dts/Makefile
	sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb bcm2837-rpi-3-b.dtb," a && mv a arch/arm/boot/dts/Makefile

> I haven't followed up on getting the DT documented so that it can be
> merged, and it sounds like Michael has some plans for changing how VCHI
> and VCHI's consumers get attached to each other so that it's not
> DT-based anyway.

I see.

> 
> From 9488974b836b1fba7d32af34d612151872f9ce0d Mon Sep 17 00:00:00 2001
> From: Eric Anholt <eric at anholt.net>
> Date: Mon, 3 Oct 2016 11:23:34 -0700
> Subject: [PATCH] ARM: bcm2835: Add VCHIQ to the DT.
> 
> Signed-off-by: Eric Anholt <eric at anholt.net>
> ---
>  arch/arm/boot/dts/bcm2835-rpi.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi
> index caf2707680c1..f5fb5c5aa07a 100644
> --- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
> +++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
> @@ -26,6 +26,14 @@
>  			firmware = <&firmware>;
>  			#power-domain-cells = <1>;
>  		};
> +
> +		vchiq {
> +			compatible = "brcm,bcm2835-vchiq";
> +			reg = <0x7e00b840 0xf>;
> +			interrupts = <0 2>;
> +			cache-line-size = <32>;
> +			firmware = <&firmware>;
> +		};
>  	};
>  };
>  



Thanks,
Mauro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Assinatura digital OpenPGP
URL: <http://lists.infradead.org/pipermail/linux-rpi-kernel/attachments/20170315/17011040/attachment.sig>