auvidea wrote:this is great work.
I would be very interested in testing the beta driver. How can I get hold of it?
As per my post, please email me.
It's not that I'm wanting to keep the driver closed, but mainly so that I know who I'm supporting as there are awkward corners (things like configuring I2C busses which vary depending on the version of Pi in use). There are some hoops to jump through to get V4L2 to work correctly too.
The first patch set has been posted to the
linux-media mailing list, and I'm just finishing off dealing with the comments/discussions from that. V2 should be tomorrow. Working with the upstream kernel is a bit of a pain though as things like DT overlays don't work. Once I've sent V2 I'll backport it to a testing Pi specific tree which is a little easier.
I also have a hybrid test app that is routing the V4L2 back into MMAL for resize (using the ISP) and display. Adding video encode should only be a plumbing job in the app, but I haven't had time to do that as yet.
auvidea wrote:Just recently we introduced new versions of the B101 and B102, where we added an 8 pin connector for I2S audio, reset and cable detect. These signals can be routed to the appropriate pins of the Raspberry GPIO connector. We include the right cable set for this connection.
Also we have designed the R100, which is a carrier board for the Raspberry compute module 3 (CM3). It integrates the B102, which is connected via 4 CISI-2 lanes to the CM3. Do you see an advantage in using 4 lanes rather than the standard 2 lanes of the RPi camera connector? We are currently sampling the R100 to beta customers. I would be happy to send you one, if you are interested.
It would be interesting to have one as a reference, likewise a B102 as our board is only 2 lane.
Sorry, at the moment I haven't time to look at audio. The kernel driver for the TC358743 in theory is set up for I2S audio, but I have no idea as to extra magic required.
I have done the calcs already on 2 vs 4 lanes.
2 lanes at ~910Mbit/s per lane should be sufficient to get 1080P50 UYVY down, which would be quite nice even if it requires an overclock on the codec block (only designed for 1080P30). 1080P60 or 1080P50 RGB24 is just beyond the available bandwidth on 2 lanes. The chroma subsampling of YUV4:2:2 is unlikely to be noticeable, particularly as most people will H264 encode which is YUV4:2:0.
The followup question is what you would do with 1080P60 seeing as it is double what the codec can cope with.....
Having said all that, the current kernel driver is only set up to run at 594Mbps/lane which just falls short for 720P60 RGB3 (again it is OK with UYVY). I need to update the DT overlays to increase the link frequency and see what I can get, but it's a balancing act in order to still handle the lower resolutions.
Based on correspondence with those on linux-media I get the impression that 720P60 on 2 lanes and 1080P60 on 4 lanes, both as UYVY are the only modes that have really been used. There's no reason why other resolutions/framerates won't work, but the TC358743 needs some little tweaks.
auvidea wrote:On the R100 the I2S audio is connected to the I2S lines of the CM3. However we have not tested this yet. It would be great, if you could have a look.
As I say, I haven't got the spare time to look at audio at the moment. I know Orbital6 was looking at it but I can't recall where he got to.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.
(you seem to have ignored my previous emails).