DM8148 ISS Capture for V4L2

Hi,

ISS is not supported through V4L2 interface. Its supported to Media controller interface. You can contact your local TI support for more details.

Regards,

Hardik Shah

Thanks for the info, my FAE is working on getting me the software. Since this new software with will use a new protocol, how is no ISS capture supposed to be performed? Through V4L2? or do we also need to use this new interface to capture from VP0 and VP1?

Thanks

I am on the same boat with you.
Previously we used DM368 board, which comes with fully functional capture/encode demo for CMOS sensor.
I don't even know where to start for DM8148 ISS capture.

Local FAE? why would they know anything about this?

Texas Instruments doesnt seem to think supporting standard linux interfaces is a good idea and supporting v4l2 isnt on their road map. They will provide you with the ipnc reference design eventually, which is a poorly coded mess that barely functions. You cant access the registers that control the pixel clock etc directly, because you have to enable an undocumented clock that is under a non disclosure agreement (and assuming you could enable this clock, that is still no guarantee that it is accessible from the A8 core, and they dont give you access to any M3 code in the ezsdk publically available) so you are left to struggle on your own and beg for help here and only here because you are under NDA.

If you just started I would highly recommend switching to broadcom / any other platform that meets your requirements as the cost of understanding and using this platform will slowly add up and delay schedule.

I totally agree with you.

In my previous DM368 design, I started with an IPNC,but only to find that its kernel base is outdated, code is very pooly architured, virtually no technical support. So I had to swtich to DVSDK, which was much easier to use.

So in this design, I was planning to use EZSDK from the beginning, now I just found out the mess about ISS. WHY DONT YOU LEAVE ISS OUT IF YOU DONT PLAN TO SUPPORT IT? it's so frustrating to customers. Our first rev DM8148 PCB is already done, now I don't know which direction to go. I am toying with idea of writing V4L2 code myself, but I have no idea how long it would take. I am the only software engineer in the company, and we already got an unrealistic project schedule.

Yeah it is really frustrating, DM8168 isn't much better, we were at least able to get capture on both video ports using v4l2 with only a little work. We are able to access basically all the components but are seeing some throughput issues and bugs.

Hongfeng,

I haven't gone down the RDK road yet. Were you able to capture on VP0 and VP1 with the dm8148 using the RDK? If so were you using discrete syncs or embedded?  We are trying to use discrete syncs and have had no luck with the EZSDK and v4l2 (even though capturing with embedded syncs through the TVP7002 seemed to work), I get a port overflow (see here if interested in more details). Our goal was to use both CAM port with ISS and VP0 with a second imager, I am starting to think that this combination is not supported anywhere.

-Ben

I haven't got the RDK yet, we just ordered it last week.
It's good news to hear that DM8127 code can run without modification on DM8148. As much as I don't like the IPNC, maybe I can just base a small portion of my code on IPNC, than run it on EZSDK.

I am not sure how well you will be able to mix-and-match the components from IPNC. They use a different processor communication API and it the M3 core wants to own the imager sub device. It seems much more similar to OMX than V4L2. I am still trying to get discrete capture working with IPNC with no luck. I would really appreciate some input from TI about this, namely, can we capture with discrete syncs in the IPNC or in the EZSDK, and does the IPNC support capture through VP0 and the CAM port simultaneously. It seems rather silly to have all these video ports yet not be able to use them. If you don't mind, keep us posted on RDK capabilities. I hear it is easier to add imagers in RDK but I do not think that ISS is supported.

Best of Luck,

Ben

I am in the same boat too. I have NDA signed and I am asking local offices a lot, but the guys din`t know nothing about ISS or some kind of documentation.

Please tell me if you found some new documentation.

Hey All,

Just thought I would make you aware of the resources that we have been able to acquire or want to acquire:

we were able to get IPNC_RDK_3.0

TMS320DM814x Imaging Subsystem (ISS) Technical Reference Manual - document SPRUH30A

Apparently there is a VCAM daughtercard that is supposed to work with the RDK, not sure how to get ahold of it.

There is an "image tuning tool", also called the DCC capture tool. We have version 1.00.00, but apparently that only works with version 2.0 of IPNC_RDK, I am not sure if there is a newer version.

Still have not been able to get capture to work on ISS even with the MT9J003. We are still working on it.

Please share back if you discover something worth mentioning.

Hi all,

Any news on getting the ISS( specifically the parallel camera Interface) going on the DM8148. I'm also in the queue for the ISS documentation. I also have the IPNC RDK V3.0.0. But modification of code is impossible due to lack of documentation. Any guidance would be appreciated.

Thanks!

Wietz

Hi All,

Are you looking for ISS support using V4L2? We have expertise in enabling ISS sensor on DM8148. Please mail me @ renjith.thomas@pathpartnertech.com

Hi Ben,

Im having a hell of a time getting anything out if my Arrow FAE on DM8148 documentation... I keep getting told that such documetation does not exist, even after referencing the doc part number you posted, with an NDA (which I have). If you dont mind my asking, did you go directly through TI, a TI 3rd party, or via a distributor rep?

For our DM36x product (also with an MT9J003), we had a rep at TI directly that helped us get NDA's signed and gather up-to-date documentation, etc. Unfortunately he's moved and I don't have a contact for SoCal TI reps.

On a side note, have you been able to find an optimal min line blanking value for the MT9J003? Documentation suggest one thing (30, doesn't work), the register wizard software suggests another (112, but slows down the max frame rate - we are trying to hit 1792x1344@30Hz and provide scaling), and I've been able to run with 60 in normal and skipping (summing, binning) modes. Just thought, I'd ask!