[Partly-Solved] VCHIQ/MMAL Camera access

[Ultibo]

This would usually trigger the VCHIQ callback which is forwarded into MMAL with reason VCHIQ_MESSAGE_AVAILABLE that does check the returned messageID to be MMAL_WORKER_BUFFER_TO_HOST and than triggers the VCHIQ_BULK_RECIEVE. But this initial callback from VCHIQ, once the buffer has been passed is not triggered.

Hi Schnoogle,

Your description above reminded me of an issue that came up while doing our VCHIQ port, it's relevance depends on your implementation so I'll ask you this first.

Do your mutex structures require initialization before use or can you just start using them immediately?

If that doesn't make sense think of it this way, under Linux you can just allocate a block of memory and pass it to mutex_lock() (or whatever the specific function name is) and it will work, under Windows you have to call CreateMutex() to initialize a mutex first before using it.

If your implementation fits in the latter then there is a case in VCHIQ which can affect the exact scenario you describe above.

[Schnoogle]

Hi Ultibo,

well I'm using semaphores and spinlocks. As far as I'm aware mutex is quite similar to the spinlock approach and ensures propper cross core handling of memory access...But to answer your question, there is no specific initialization for the spinlock/mutex necessary to be called before they can be used.

Never the less I'm tending to doubt that this could finally be the root cause of my issue as I do have the assumption that if the complete MMAL and VCHIQ interface is working for a capture up to 128x100 pixel than why shouldn't it when going beyond that like with 128x128 pixel.
I've also dumped every VCHIQ message sent to the VC and compared witheach other - in the 128x100 and the 128x128 scenario.
The most weird thing is that the final message going to VC for 128x128 and not getting any response from the VC looks completely similar except the memory address of the "client_context" as called in MMAL terms is passed. Also the VCHIQ shared local state looks completely the same in the 128x100 (working) and 128x128 (not-working) cases.

Could it be that there is some additional initial "config" necessary that I might have missed when creating the MMAL component using VCHIQ interface?
From what I've seen is, that the camera ports that where initialy created with the camera component are giving a 640x480 capture size. But even if I let the port setting un-touched and only pass a buffer that would be able to hold the captured data I'm faced with the same behavior, VCHIQ just did not respond to the message that passes the buffer....

Thx again for your restles support
Schnoogle

[Ultibo]

But to answer your question, there is no specific initialization for the spinlock/mutex necessary to be called before they can be used.

Alas, the particular case I was thinking of only applies if your lock structures (spin/mutex) require initialization before use.

VCHIQ just did not respond to the message that passes the buffer....

How are you determining that the VCHIQ does not respond? Is there no interrupt received in response to the message or do you just not receive the callback?

I know you have a simplified implementation but from your description it sounds similar overall to the original (and I'm guessing you didn't want to rewrite it all from scratch).

Whenever MMAL sends a VCHIQ_IOC_QUEUE_MESSAGE the completion thread will wait for a VCHIQ_IOC_AWAIT_COMPLETION which is what then signals the VCHIQ_MESSAGE_AVAILABLE etc.

There are no timeout or abort mechanisms in that process so I read it that the VCHIQ will always respond to every message, unless of course there is something else that is preventing it from doing so.

[Schnoogle]

Hi Ultibo,

well, the VCHIQ is setting up some memory space which will be shared between GPU and ARM. When sending a new message to VCHIQ this memory space is filled with the appropriate data, and a in specific part of it - the SHARED_STATE - flag will be set that there is new data available and the GPU doorbell will be rung to let the GPU do it's work.
Usually than the GPU will either just update a flag in the SHARED_STATE that the work is done and that some task should be triggered on the ARM side. In the linux driver this is done in a separate thread where it waits for this flag being set or it handles the ARM Doorbell IRQ to initialize the ARM processing.

In my specific scenario when using the 128x100 caputure size on the camera everything works fine. Meaning the GPU doorbell is rung and the trigger on the ARM side is set by the GPU and the ARM is continuing working and so forth...

However, once I send the message to the VCHIQ that contains the data buffer for the captured data the program rings the GPU doorbell, but the GPU does never update the ARM state/flag nor does it ever ring the corresponding door bell. When I have encountered this in the very beginning than the green LED of the Pi is blinking some code like 9 times fast - pause - 9 times fast - pause ....... but in this case nothing. It seems like the GPU is just taking the message and forgets that is should respond to it or at least raise some error message that is does not accept this one ....

Does this more or less high level explanation answers your question, how I know that the VCHIQ/GPU is not responding to my message?

BR Schnoogle