Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx> writes: > Em Fri, 27 Jan 2017 13:54:57 -0800 > Eric Anholt <eric@xxxxxxxxxx> 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. 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. From 9488974b836b1fba7d32af34d612151872f9ce0d Mon Sep 17 00:00:00 2001 From: Eric Anholt <eric@xxxxxxxxxx> Date: Mon, 3 Oct 2016 11:23:34 -0700 Subject: [PATCH] ARM: bcm2835: Add VCHIQ to the DT. Signed-off-by: Eric Anholt <eric@xxxxxxxxxx> --- 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>; + }; }; }; -- 2.11.0
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel