Page 1 of 1

Embedded data lines and kernel panic

Posted: Wed Mar 06, 2019 4:11 pm
by inac
Can someone tell me what the precise the following parameters mean in MMAL_PARAMETER_CAMERA_RX_CONFIG_T?

Code: Select all

   - data_lanes
   - encode_block_length
   - embedded_data_lines
   - image_id

We set our Sony camera to output 0 embedded datalines. Then we set the following value

Code: Select all

rx_config.embedded_data_lines = 0;

The result is that everything works fine but only for 3.5 min. Then the kernel panics and the RPi is completely dead. After some time we discovered that setting

Code: Select all

rx_config.embedded_data_lines = 2;

it works.

But why setting it to 2 while we set the Sony camera to "no EBD"? Which values is best to set?

Re: Embedded data lines and kernel panic

Posted: Wed Mar 06, 2019 4:17 pm
by 6by9
data_lanes is how many CSI2 data lanes you have connected and active between source and receiver.

encode_block_length is related to DPCM unpacking - ignore it.

embedded_data_lines is how many lines of buffer the peripheral is told to expect for any CSI2 data type field that doesn't match image_id.

image_id is the expected CSI2 data type field for the image data. Anything that doesn't match this will be put in the buffer which has the MMAL_BUFFER_HEADER_FLAG_CODECSIDEINFO flag set.

Re: Embedded data lines and kernel panic

Posted: Tue Mar 12, 2019 3:35 pm
by inac
Thanks! Can you give some more information about the embedded_data_lines. It's not totally clear what happening when setting this. E.g if my camera outputs 2 embedded data lines, x lines video and 1 line PDAF data.

Code: Select all

PDAF   (= Phase Detection Auto Focus)

1) Is setting the embedded_data_lines a value for allocating another buffer (separated from the port pool) where the EDL are stored (or are the EDL stored in the buffers from the port pool)?
2) Can I set a size much bigger than the actual EDL?
3) Is it possible to check if the size is to small, instead of panic the kernel?
4) Is (in my case) the PDAF line and EDL stored in one buffer (one callback) and so the PDAF is also seen as part of the EDL?

Re: Embedded data lines and kernel panic

Posted: Tue Mar 12, 2019 4:27 pm
by 6by9
The component picks up two buffers supplied by the user per frame, and drops frames if 2 aren't available. One is used for all data that matches the configured data_type/imagea_id field, and one for everything else (normally the embedded data lines). The embedded_data_lines value therefore shouldn't too much as it should be smaller than the image buffer size.
The setting is passed into the peripheral to configure when it should generate an interrupt for the end of embedded data. In this case that interrupt isn't enabled, therefore it should make no difference.

In theory the image buffer should be treated by the peripheral as a circular buffer, so if more lines than expected are received then it cycles back round to the top. I'm not 100% convinced that the hardware is behaving as expected. The easiest thing to do is to increase port->format->es->video.height to add a couple of extra lines of padding to the buffer. port->format->es->video.crop.height reflects the genuine height of the image data, so downstream components should use that and totally ignore the padding.

Sorry, I can't say how your device is transferring the PDAF data. I would expect it to be in the embedded data, but it should be in the datasheet for your sensor, or the manufacturer should be able to support you with that information.

Re: Embedded data lines and kernel panic

Posted: Wed Mar 13, 2019 8:49 am
by inac
Thanks that helps a lot! In my experience is to less embedded_data_lines will panic the kernel and crash. To less image buffer size will give errors seen with

Code: Select all

sudo /opt/vc/bin/vcdbg reloc
and also crashes at the end. So what I understand from you that its save to add all the possible additional lines to the image buffer height and the embedded_data_lines to be 100% safe.